Все новости от 29 мая 2006 г.

Oracle: силы рынка не способны сделать ПО безопасным

Выступив в четверг на конференции WWW2006 в Эдинбурге, Мэри-Энн Дэвидсон заявила, что «большинство программистов не обучено думать в терминах безопасности и надежности», и вместо этого они насаждают культуру «patch, patch, patch», что обходится отрасли в $59 млрд. Она утверждает также, что британцы особенно хорошие хакеры, так как «их характер идеален для хакерства — они технически образованны, не очень уважают власти и чуточку склонны к криминальному поведению».

Характеризуя состояние индустрии программного обеспечения и безопасности в целом, Дэвидсон сказала, что проблема ненадежного и небезопасного ПО становится все острее, и что индустрия достигла «критической точки». «Директора жалуются, что то ПО, которое они получают от своих поставщиков, неприемлемо с точки зрения безопасности».

Дела в бизнесе программного обеспечения обстоят настолько плохо, что теперь это «проблема национальной безопасности», и на повестке дня стоит принятие соответствующих законов, заявила Дэвидсон. «Недавно я провела неформальный опрос директоров по безопасности в CSO Council, и многие из них согласились, что отрасль требует государственного регулирования». Если это случится, отрасль должна пенять только на себя, сказала Дэвидсон. «Индустрия не желает регулирования, но если вы его не хотите, то сами должны работать лучше».

Дэвидсон указала также на «хакерский менталитет», приводящий к тому, что эксплойты, способные причинить «ущерб на миллион долларов… свободно распространяются на конференциях». По ее словам, существует большая разница между теми, кто работает в бизнесе программного обеспечения, и инженерами, «обученными думать в первую очередь о безопасности и надежности».

«Что, если строители станут строить мосты так же, как программисты пишут код? Тогда утром, по пути на работу, вы можете очутиться на синем мосту смерти», — заключила она. 

 Предыдущие публикации:

Обсуждение и комментарии

	Black Bat 29 May 2006 10:30 AM
_«Что, если строители станут строить мосты так же, как программисты пишут код? Тогда утром по пути на работу вы можете очутиться на синем мосту смерти», — заключила она._ Тех, кто пытается прикрепить к мосту мешок гескогена, обычно отстреливают... В области ПО законы более либеральны...
	Поручик 29 May 2006 10:41 AM
2Black Bat А как быть с теми, кто экономит на безопасности продуктов? Ведь по отношению к ним законы предельно либеральны.
	Roma - voodoo3000mail.ru 29 May 2006 11:32 AM
>Выступив в четверг на конференции WWW2006 в >Эдинбурге, Мэри-Энн Дэвидсон заявила, что >«большинство программистов не обучено думать в >терминах безопасности и надежности» и вместо этого >они насаждают культуру «patch, patch, patch» Эх, что-то это мне напоминает, например: "кибернетика - продажная девка империализма" или вот ещё дело врачей, борьба с космополитизмом вспоминается... >Она утверждает также, что британцы особенно >хорошие хакеры, так как «их характер идеален для >хакерства — они технически образованы, не очень >уважают власти и чуточку склонны к криминальному >поведению». Развивая тему, можно добавить, что японцы особенно склонны к карате, немцы к фашизму, русские к водке, индусы к йоге, итальянцы к макаронам и так далее. Другими словами - бред какой-то. Короче - глупое заявление.
	eXOR 29 May 2006 11:36 AM
Да уж. То сети у вас вебами становятся. То англичане хакерами... По поводу мостов... если бы милая дама знала как делаются мосты... или как работают строители...
	Roma - voodoo3000mail.ru 29 May 2006 12:10 PM
>«Индустрия не желает регулирования, но если вы его >не хотите, то сами должны работать лучше». Может это она должна работать лучше, она же вроде директор по безопасности. Или я чего-то не понимаю. >и на повестке дня стоит принятие соответствующих законов Которые бы давали преференции фирме Oracle и давили бы всех остальных, а также давали бы возможность сажать людей в тюрмы под предлгом что у них де «хакерский менталитет» (цитата). Короче, директор по безопасности не виноват в том, что в Oracle дыра,а виноваты все остальные: правительство, что не приняло закон, программисты - почтому что все они безответственные, англичане, потому что у них хакерский менталитет и т.д.
	Q 29 May 2006 12:11 PM
А что кто-то видел мост который нельзя всорвать?
	anonymous c LOR 29 May 2006 1:16 PM
eXOR, мосты тоже делают индусы, прослушав недельный курс "обучения"?
	labs.google.com 29 May 2006 1:20 PM
зд-нет перекошена, однако рассказывает, о чем директоры жалуются и не слова о том, что labs.google.com основательно пропатчил Wine и выпустил Picasa для Linux пора уже каждую новую программу для Windows проверять на совместимость с Linux/Wine глядишь и жалоб меньше будет
	Shamlo 29 May 2006 3:06 PM
Сравнение с мостами, конечно же, неуместно. Мосты - это статические конструкции, в которых многократный запас прочности не так негативно сказывается на потребительских качествах. Но в целом она права: отрасль не может победить это зло рыночными методами. Так что ждем какого-нибудь закона о том, что программисты, разрабатывающие критически важное ПО, должны получать зарплату не меньше определенного уровня. Причем этот уровень должен быть таким, чтобы про ценовую конкуренцию в этом секторе можно было забыть, и чтобы вопрос о найме индусов даже не стоял.
	Сергей Т. 29 May 2006 4:51 PM
Если проводить адекватную аналогию с мостами, то программные продукты нужно сравнивать не с одним, а с миллионами мостов, объединенных транспортными развязками друг с другом, по которым все время движутся сотни миллионов автомашин. И построены они совсем разными частными строительными фирмами. И порою кое-где на них порой промышляют банды преступников. За этим должны следить службы безопасности. И вот один из таких гаишников (дамочка из Оракла) вместо того, чтобы следить за безопасностью, начинает орать, что "все, блин, достали... Эти бандюганы посмели напасть даже на мою будку... Нужно все эти мосты отдать под руководство одной государственной конторы." Как будто такая контора будет эффективней бороться с преступностью, чем каждый хозяин на своей грядке. Полиция, конечно, нужна. Но нужно и самим замки на двери вешать...
	anonymous c LOR 29 May 2006 8:29 PM
Сергей Т., у вас очень богатое воображение. речь идет всеголишь о том, чтобы софт писали квалифицированные разработчики. К сожалению, такой софт будет намного дороже того, что пишут индусы для MS, поэтому нужно придумать какой-то механизм, для того чтобы качество ПО повышалось.
	sm4 - s999999999rambler.ru 29 May 2006 9:07 PM
Да этому способу писать программы миллион лет. Просто надо записывать "жизненно важные" элементы в нестираемую и неперезаписываемую память. А если полчаса подумать то ещё чего-нибудь придумается. Но что-то никто не заинтересован в этом. Даже драный Windows 3.1 перенесенный на PDA,и продаваемый под маркой 2005 mobile стал в 1000-и раз безопасней без всяких файрволов и антивирусов.
	Индус из МС 30 May 2006 1:53 AM
механизмы для повышения качества кода МС давно придумала и внедрила - prefix и prefast... и вроде заставила своих разработчиков прочитать Writing secure code (это книжка, как грамотно писать код с акцентом на безопасность, на что одни забивают, а другие вообще не знают... потому мнение секьюрити-дамочки из Оракла - "большинство программистов не обучено думать в терминах безопасности и надежности" - вполне обосновано) еще МС выпустила SP2 для XP, ужесточив ряд параметров/настроек безопасности, включая IE собсно, этим объясняется сильное уменьшение кол-ва багов за последние полтора-два года года, сравнительно с 2001-2003 гг.
	Alexander S. Kharitonov 30 May 2006 8:57 AM
2 Shamlo: > Так что ждем какого-нибудь закона о том, что программисты, разрабатывающие критически важное ПО, должны получать зарплату не меньше определенного уровня. И что будет со свободным софтом? При том, что использование свободного софта обеспечивает большую безопасность, в случае такого государственного регулирования более безопасный Linux с Apache придётся менять на менее безопасный Windows с IIS - очевидно, что разработчики свободного софта не смогут заниматься формальностями, а в Microsoft легко их пройдут.
	Tolik 30 May 2006 9:17 AM
"вы бы не сели в самолет, построенный программистами" Гы, современный Боинг или Эрбас это по сути компьютер с крыльями. Там стоимость разработки софта в себестоимости как бы не поболее, чем металла или его обработки. Так что самолеты ноне в значительной части создаются именно программистами. И ничего, вполне себе аффтар на них летает. Кстати, большинство просто не в курсе, как оно там у строителей. Мосты не помню в последнее время, а крыши, бывалочи, падают.
	Shamlo 30 May 2006 9:55 AM
> Alexander S. Kharitonov: > И что будет со свободным софтом? При том, что использование > свободного софта обеспечивает большую безопасность... Какой-то очень мрачный взгляд на проблему. Мне вообще не кажется, что свободному софту в этом случае что-то угрожает. Если он свободный и платный, то он также легко пройдет все формальности. А если он бесплатный, то его это вообще не коснется. По идее, цель государственного регулирования должна заключаться в том, чтобы насильно перераспределить усилия, затрачиваемые компаниями. Сейчас они тратят, условно говоря, $100 на з/п индусам и $1000 на маркетинг для того, чтобы убедить всех в том, что получившееся говно является безопасным продуктом. А в результате регулирования ситуация должна будет зеркально отразиться.
	Банч 30 May 2006 6:17 PM
по статье: странно как-то обвинять собственную компанию в бессилии т.е. признавать: да, Оракл всегда будет дырявым, мы не способны сделать его безопасным :)) может что-то с переводом не то?
	sm4 - s999999999rambler.ru 31 May 2006 1:48 AM
Самолет, как видно, строят не только программисты. Вспомните, кто первый протестует против надежного шифрования данных на компьютерах - спецслужбы, причём в унисон и английские и американские и русские. Здесь у них странное единодушие. А хакеры просто путаютя под ногами, хотя всё внимание пытаются сконцентрировать на них. Вспомните гибель на "Колумбии". Цетр управления НАСА был немедленно физически отключен от интенета. Почему ??? Почему ни программно, типа "Disable Connection ?" "Yes"
	RIK 1 Jun 2006 4:14 AM
Я согласен с Индусом из МС. Я думаю, что резервы улучшения качества кода в больших проектах путем организационных/административных мероприятий невелики. А выход в развитии автоматических систем верификации кода.
	Ender 2 Jun 2006 8:10 AM
2Shamlo: "Сейчас они тратят, условно говоря, $100 на з/п индусам и $1000 на маркетинг для того, чтобы убедить всех в том, что получившееся говно является безопасным продуктом. А в результате регулирования ситуация должна будет зеркально отразиться." Да ну? Сейчас, грубо говоря, продукт написанный 10-тью индусами стоит $100 x 10 + $1000 = $2000. Заставят поднять им зарплату и будет стоить $1000 x 10 + $1000 = $11000. При этом будет то-же самое "говно", т.к. даже если человеку платить в 10 раз больше против того что он уже зарабатывает, он не поумнеет. Может быть будет работать немного усерднее и/или больше, но не более того.
	Shamlo 2 Jun 2006 8:50 AM
> Ender: т.к. даже если человеку платить в 10 раз больше против > того что он уже зарабатывает, он не поумнеет. Может быть > будет работать немного усерднее и/или больше, но не более того. Это более чем очевидно. Но речь о другом. Индусов просто перестанут нанимать, так как за счет них нельзя будет сэкономить, а на нормальную зарплату выстроится очередь из белых, окончивших MIT.
	linuxsuxx.narod.ru - lssuxx.com 2 Jun 2006 9:25 PM
то что безопасной ОСн ет и не будет киногда тока ребенок не знает. че вы тут лепечете...спецы бля
	RIK 2 Jun 2006 9:38 PM
2 Shamlo У вас какое-то странное представление о программистах, работающих в МС.
	Shamlo 3 Jun 2006 1:19 AM
> RIK: У вас какое-то странное представление о программистах, > работающих в МС. А где я говорил про МС?
	RIK 3 Jun 2006 9:47 PM
2 Shamlo >А где я говорил про МС? Это подразумевалось. Впрочем, я готов исправить свое утверждение - у вас странное представление о программистах, работающих в американских фирмах над большими проектами. Мнение, что там работают преимущественно "индусы с образованием в виде двухнедельных курсов" имеет такое же отношение к реальности, как рассказы Задорнова об американцах (которые "ну тупые") или о том, что по Москве разгуливают медведи с балалайками. Соображения о том, что нужно сделать, чтобы "перестали нанимать (необразованных) индусов", совершенно несерьезны; они сродни рассуждениям как разогнать медведей с Красной площади.
	Shamlo 3 Jun 2006 10:30 PM
2 RIK: А как же все эти разговоры про аутсорсинг? Неужели ничего такого нет? Я вполне допускаю то, что в американских фирмах над большими проектами работают лучшие из лучших, и то, что на аутсорсинг они отдают только самые тривиальные задачи. Но тогда общая картина не сходится. Возникает вопрос: почему в результате получается такое г.?
	RIK 4 Jun 2006 3:23 AM
>А как же все эти разговоры про аутсорсинг На аутсорсинг по преимуществу отдается сопровождение и багфиксинг, а также локализация и создание версий для нишевых рынков. Иногда - разработка прототипов. Новые коммерческие разработки ведутся почти исключительно на территории США. Квалификация программистов, работающих в крупных фирмах, довольно высока, равно как образовательный уровень - скажем, и для МС и для Оракла стандартное требование - MS или PHD. >Возникает вопрос: почему в результате получается такое г.? А вы сами писали что-нибуть больше, скажем, мегабайта кода? Здесь тусовался некоторое время назад некий glassy - человек писал CAD под линукс и тоже любил весьма нелестно отзываться о микрософтовских программистах. Когда он выложил свой код я решил посмотреть на его творение. Открыл первый попавшийся файл и сходу обнаружил пару переполнений буфера, а также еще с десяток проблем помельче. Я не наезжаю на glassy - человек, способный написать что-либо стоящее (и работающее) заслуживает всяческого уважения. Людям свойственно ошибаться; когда объем кода становится достаточно большим, вероятность ошибки быстро растет. Впрочем, программист высокой квалификации допускает такие ошибки редко, а code review и тулы вроде prefix и prefast дополнительно снижают их вероятность. Проблемы больших проектов сегодня, по-моему, другие. Я назову пару таких проблем: 1. Legacy code. Море кода, написанного лет 10 назад. Этот код уже не отвечает вовременным требованиям, но отказаться от него не возможно. Он переписывается, и качество переписанного кода заметно выше. Однако чтобы все переписать нужно время. 2. Сложность программных систем заметно превзошла возможности человека по пониманию. Уже давно нет человека, который бы знал полную логику работы и все взаимосвязи. Это принципиальная проблема, дальше будет только хуже. Частичное решение этой проблемы я вижу в развитии языков более высокого уровня (Java и C# - шаги в правильном направлении) и средств source code analysis.
	tstone - saldomail.ru 4 Jun 2006 9:09 AM
А вдруг есть языки программирования, где "переполнение буфера" невозможно даже теоретически?! "А мужуки-то не знают!"
	tstone - saldomail.ru 4 Jun 2006 9:24 AM
А еще в современных процах есть средства, используя которые можно эти переполнения буферов отлавливать аппаратно. Если средства есть, а ошибки продолжают валиться, значит эти средства не используют? Не уж то о них не знают?! Эт вряд ли. Значит не используют сознательно?!
	Shamlo 4 Jun 2006 9:37 AM
> RIK: скажем, и для МС и для Оракла стандартное требование - MS или PHD. Требования явно завышены. Чтобы быть хорошим программистом PhD совершенно не нужен. Ну и потом я не верю в то, что в америке есть столько людей со степенью PhD, сколько их работает программистами в крупных фирмах. > А вы сами писали что-нибуть больше, скажем, мегабайта кода? Сложный вопрос. Я участвовал в проектах, объем кода которых был больше мегабайта, но я был не единственным участником. Если же говорить о полностью моих проектах, то опять-таки нет однозначного ответа. Объем ручного кода редко выходит за 100 килобайт, ибо нет цели написать одну программу, которая будет уметь все. Комплексные задачи обычно разбиваются на несколько связанных модулей, которые разрабатываются и поддерживаются независимо. Если же брать не только ручной код, а еще и тот, который автоматически генерируется скриптами, то бывает и больше мегабайта. А если еще сделать моментальный снимок кода в тот момент, когда компилятор уже развернул все шаблоны, то там наверняка будут десятки мегабайт. В общем, я это к тому, что большой проект можно получить двумя способами: запрячь две сотни индусов, которые напишут мегабайты кода за неделю, или же нанять пяток программеров, которые нагенерят его еще больше, но не вручную, а при помощи написанных ими специальных программ. Очевидно, что второй вариант будет содержать меньше ошибок. Разница в подходах такая же как между "регулярно убирать мусор" и "не мусорить". Конечная цель вроде бы одна и та же, но второй подход проще организовать чисто технически, поэтому высокой эффективности можно добиться менее изощренными инструментами. > Впрочем, программист высокой квалификации допускает такие > ошибки редко, а code review и тулы вроде prefix и prefast > дополнительно снижают их вероятность. Тулы - это, конечно, прикольно. Но многое можно сделать и без них, если подойти творчески. Например, если в файл, который включается во все модули проекта, добавить одну лишь строку: #undef sprintf, то безопасность кода резко возрастет. Люди просто не смогут вызвать эту функцию и будут вынуждены использовать её безопасный аналог.
	Ender 4 Jun 2006 9:41 PM
2Shamlo: "Это более чем очевидно. Но речь о другом. Индусов просто перестанут нанимать, так как за счет них нельзя будет сэкономить, а на нормальную зарплату выстроится очередь из белых, окончивших MIT." Я так понимаю сейчас выпускники MIT прямо с церемонии вручения диплома сразу отправляются на помойку к бомжам или жарить гамбургеры, т.к. все стоящие места уже заняты дешевыми индусами. Ну выйдет тысяча этих белых людей на супер-зарплату, а остальные 99 тысяч рабочих мест как были, так и остануться за индусами, только получающими в 10 раз больше.
	Ender 4 Jun 2006 9:48 PM
2Shamlo: "Но многое можно сделать и без них, если подойти творчески." Если подходить творчески, то языки позволяющие sprintf не должны использоваться для написания прикладного софта. :-)
	Shamlo 5 Jun 2006 8:33 AM
> Ender: Я так понимаю сейчас выпускники MIT прямо с церемонии > вручения диплома сразу отправляются на помойку к бомжам или > жарить гамбургеры, т.к. все стоящие места уже заняты дешевыми > индусами. Не, немного не так. Они все нормально работают и сейчас, но их очень мало, так как профессия перестала быть престижной. Поэтому вместо написания хорошего кода они работают архитекторами, проектировщиками и прочими рисовальщиками диаграмм. Т.е. качество кода от них слабо зависит. Это во-первых. А во-вторых, даже если профессия не станет престижной, то 99 тысяч рабочих мест не останутся за индусами по чисто экономическим соображениям. Многие компании просто уйдут с рынка, так как хороших специалистов им не хватит, а поделки индусов не будут хорошо продаваться по тем ценам, которые позволят получать прибыль с учетом возросшей зарплаты.
	Shamlo 5 Jun 2006 8:41 AM
> Ender: Если подходить творчески, то языки позволяющие sprintf > не должны использоваться для написания прикладного софта. :-) Шутку оценил. Перехожу на Яву :) А если серьезно, то, несмотря на все преимущества такого подхода с точки зрения безопасности, есть маленькая чисто психологическая проблема. Языки без прямого доступа к памяти очень похожи на машины, в которые встроен ограничитель скорости на уровне 60 км/ч. Вроде бы машина всем хороша и задачи свои замечательно решает, но наличие органичителя сильно давит на психику.
	Ender 5 Jun 2006 9:09 AM
2Shamlo: "Это во-первых. А во-вторых, даже если профессия не станет престижной, то 99 тысяч рабочих мест не останутся за индусами по чисто экономическим соображениям. Многие компании просто уйдут с рынка, так как хороших специалистов им не хватит, а поделки индусов не будут хорошо продаваться по тем ценам, которые позволят получать прибыль с учетом возросшей зарплаты." Ну хорошо. Вместо "тупого" индуса придет "тупой" америкос, немец, австралиец еще кого подставь. Нету в мире столько высококвалифицированных программистов. Мне довелось и читать и править как пишут лучшие (я подчеркиваю ЛУЧШИЕ, по мнению их начальства) программисты забугорной (вполне успешной) конторы, иметь отношение к найму программистов здесь, в России. Один нормальный приходится на сотню. Очень многие не знают элементарных понятий ООП. Человек что-то писал объектно-ориентированное, но на вопрос: "Что такое полиморфизм?" начинает строить догадки. Берешь с brainbench-а десяток вопросов, даешь человеку ответить, один-два правильных ответа. "А если серьезно, то, несмотря на все преимущества такого подхода с точки зрения безопасности, есть маленькая чисто психологическая проблема. Языки без прямого доступа к памяти очень похожи на машины, в которые встроен ограничитель скорости на уровне 60 км/ч. Вроде бы машина всем хороша и задачи свои замечательно решает, но наличие органичителя сильно давит на психику." Ни работодатели, ни бизнес уже давно не требуют "быстрой езды" (да и не требовали, в общем-то), за исколючением редких случаев, где количество перемолотой информации в секунду и есть одна из ключевых характеристик техпроцесса. Зато они требуют надежности, безопасности, предсказуемости поведения на дороге, ремонтопригодности, и при этом низкой стоимости. А то что больше 60-ти километров ехать нельзя, не страшно, тише едешь дальше будешь, как говориться.
	Tolik 5 Jun 2006 10:44 AM
2 Shamlo > Очевидно, что второй вариант будет содержать меньше ошибок Гы, гы ... Как-то имел несчастье пересечься с хреновиной, массово генерирующей код на основе шаблонов. Кларион называлось поделие. Бррррр .... Мало отлаживать генерируемый ею глюкавый код, так еще отлаживать ничуть не менее глюкавые шаблоны. А сколько апдейтов выходило, чуть не каждые несколько дней - и всё как раз шаблоны оно правило. Ох как не очевиден второй вариант ...
	Serg 5 Jun 2006 12:45 PM
2 Tolik: как раз более очевиден! Вы только представьте работу такого генератора ошибок! Сколько ошибок вы сможете исправить теперь, точно наперед зная, где они! Раньше как - ползаешь на карачках по коду.. а теперь - точно знаешь, где и какую ошибку тебе сгенерили! Лафа!
	Shamlo 5 Jun 2006 2:06 PM
> Ender: Ну хорошо. Вместо "тупого" индуса придет "тупой" > америкос, немец, австралиец еще кого подставь. Нету в мире > столько высококвалифицированных программистов. Ну под индусами я подразумеваю не национальность, а именно низкую квалификацию. Т.е. "тупой" америкос от этнического индуса ничем особо не отличается. Да, хороших программеров очень мало, но реально их и не нужно много. Просто сейчас их требуются миллионы, потому что многие тысячи контор занимаются разработкой какой-то херни. Например, разрабатывают свой "уникальный" антивирус, свой фаервол или же свой каталогизатор цифровых фотографий. И это не случайно. Дело в том, что индусы дают им возможность делать разрабатываемые продукты неприлично дешевыми, расширяя тем самым рынок сверх всякой меры. Согласись, что покупка каталогизатора для фоток за $39.99 и покупка того же самого каталогизатора за $999 - это два совершенно разных по степени отвественности действия. В первом случае, можно банально повестись на маркетинг и поверить в любые сказки, а во втором ты уже задумаешься о покупке серьезно и проанализируешь то, есть ли у тебя такая потребность на самом деле. Если у работодателя не будет возможности нанимать криворуких индусов за $100, то рынок сузится настолько, что хороших программистов хватит на всех его участников, и разрабатывать они будут не всякий хлам, а действительно нужные профессионалам программы - бухгалтерский софт, базы данных и т.д. А каталогизаторы для фоток пусть делают энтузиасты. > Ни работодатели, ни бизнес уже давно не требуют "быстрой езды" Это не потому, что им не надо, а потому, что они мыслят реалистично, и на них жестко давит фактор цены разработки, которую им всячески хочется уменьшить. Не любой ценой, но тем не менее...
	Shamlo 5 Jun 2006 2:10 PM
> Tolik: Мало отлаживать генерируемый ею глюкавый код, так еще > отлаживать ничуть не менее глюкавые шаблоны. Шаблоны - это несколько иной уровень. Ошибки в них легче обнаруживаются, так как проявляются во многих местах.
	Утрук 5 Jun 2006 3:09 PM
2Shamlo: "Просто сейчас их требуются миллионы, потому что многие тысячи контор занимаются разработкой какой-то херни." Ага. Для езды по дороге требуется всего 5 типов т.с. - велосипед, мотоцикл, городской автомобиль, внедорожник и грузовик. А народ занимается всякой херней, столько марок машин вокруг. А ещё, есть только один кисломолочный продукт - кефир, а народ навыдумывал всякой херни вроде ряженки, йогурта, бифидока, да еще придумал распаковывать это в разную тару. "Например, разрабатывают свой "уникальный" антивирус, свой фаервол или же свой каталогизатор цифровых фотографий. И это не случайно. Дело в том, что индусы дают им возможность делать разрабатываемые продукты неприлично дешевыми, расширяя тем самым рынок сверх всякой меры." Ну и пусть разрабатывают. Коли это кто-то покупает, значит это нужно. "действительно нужные профессионалам программы - бухгалтерский софт, базы данных и т.д. А каталогизаторы для фоток пусть делают энтузиасты." И я уже не говорю что база данных нужна одна. Придумывание всяких разных баз данных - тоже признак занятия херней. Будут её делать специально обученные очень умные, очень честные, очень высокооплачиваемые люди (кстати в Oracle, который продает ох....о дорогой софт полно индусов, а вы не знали?). Эта база данных будет работать на любой платформе,... постойте... разные платформы! Вот тут точно страдают херней. Платформа должна быть одна. Кстати, если дело повернется именно так, то Linux ей точно не будет. :-) "Согласись, что покупка каталогизатора для фоток за $39.99 и покупка того же самого каталогизатора за $999 - это два совершенно разных по степени отвественности действия." Конечно. $999? No fucking way! Даже если это единственный в мире каталогизатор фоток. "Это не потому, что им не надо, а потому, что они мыслят реалистично, и на них жестко давит фактор цены разработки, которую им всячески хочется уменьшить. Не любой ценой, но тем не менее..." Ключевое слово "реалистично".
	Shamlo 5 Jun 2006 4:35 PM
> Утрук: Ага. Для езды по дороге требуется всего 5 типов т.с. - > велосипед, мотоцикл, городской автомобиль, внедорожник и > грузовик. А народ занимается всякой херней, столько марок > машин вокруг. Именно так. Напридумывали всякой разнообразной ерунды, а до идеала также далеко как и было в самом начале. У каких-то марок излишне мощный движок, но комфортность салона не выдерживает никакой критики. У других - наоборот. Дело в том, что кое-где существует проблема монополии (мы все прекрасно знаем где), а кое-где ровно обратная ситуация. Т.е. компаний слишком много и им просто необходимо слиться в одну большую ради повышения качества продукта. С машинами может быть не очень удачный пример, но, скажем, для случая баз данных можно смело утвержать, что на рынке вполне достаточно трех СУБД - самая быстрая, самая надежная и самая функциональная. В идеале, все программисты, которые занимаются базами данных, должны заниматься ими в одном из этих направлений, работая в соответствующей компании. При этом важно понимать, что чудес не бывает и за надежность по-любому придется заплатить скоростью, а за скорость функционалом. В свете этого больше всего бесит агрессивный маркетинг, цель которого в том, чтобы убедить потребителя в том, что MSSQL удачно сочетает в себе все три преимущества. При этом на деле уже через пару дней работы с сервером понимаешь, что он далеко не так быстр и далеко не так надежен. Функционален... это да, но не более того. > Ну и пусть разрабатывают. Коли это кто-то покупает, значит это нужно. Покупают. Но не потому, что реально нужно, а потому, что очень дешево. > Эта база данных будет работать на любой платформе,... > постойте... разные платформы! Разные платформы должны поддерживаться путем банальной перекомпиляции соответствующим компилятором. Для этого придуманы различные стандарты, которые поддерживаются одновременно на большинстве платформ. Нужно активно их использовать при разработке. > Конечно. $999? No fucking way! Даже если это единственный в > мире каталогизатор фоток. Об этом и речь. Неправильно отвлекать хороших программистов на написание каталогизаторов фоток в то время, когда их не хватает тем, кто разрабатывает СУБД. Однако в условиях свободного рынка легко может сложится ситуация, когда разработчик каталогизатора сможет заплатить больше, так как ему нужно лишь один-два программера. При этом таких контор сотни и каждая, естественно, разрабатывает свой каталогизатор. В результате, Oracle вынужден набирать индусов и как-то плясать уже от этого. Ведь ему программисты нужны сотнями, и если он каждого будет переманивать более высокой зарплатой, то разорится моментально.
	RIK 5 Jun 2006 10:57 PM
2 Shamlo Вы продолжаете обсуждать несуществующие проблемы. В настоящее время в крупных американских фирмах вроде МС или Оракла квалификация программистов весьма высока. Поднятие квалификации программистов не даст адекватного роста качества софта; этот резерв уже выбран. 2 Ender >Мне довелось и читать и править как пишут лучшие (я подчеркиваю ЛУЧШИЕ, по мнению их начальства) программисты забугорной (вполне успешной) конторы, иметь отношение к найму программистов здесь, в России. Так было 6-7 лет назад. Спад 2000-2001 позволил крупным фирмам заметно улучшить состав программистов. Посмотрите на современный код, который пишут в МС - он вполне неплох. Во всяком случае, я сомневаюсь, что выпускники MIT пишут заметно лучше. (Здесь еще нужно делать поправку на размер конторы и "технологический процесс". Например, во всех крупных фирмах, какие я знаю, программистов постоянно перекидывают на разные задачи. Делается это для того, чтобы не было незаменимых. Как результат - стабильность процесса, но отсутствие выдающихся образцов в программировании).
	Shamlo 5 Jun 2006 11:11 PM
> RIK: Поднятие квалификации программистов не даст адекватного > роста качества софта; этот резерв уже выбран. Значит надо поднимать качество менеджмента, чтобы он ставил программистам более реалистичные сроки.
	RIK 6 Jun 2006 1:09 AM
>Значит надо поднимать качество менеджмента, чтобы он ставил программистам более реалистичные сроки. Да, такая проблема существует. Но опять же, и здесь резервы невелики. А именно - сокращение числа новых фич и увеличение срока разработки очевидно способно поднять качество продукта, но опять же - не кардинально. Еще раз - единственный существенный резерв роста качества софта я вижу в развитии систем Source code analysis. Остальные резервы уже в основном выбраны ИМХО.
	Shamlo 6 Jun 2006 9:07 AM
> RIK: Еще раз - единственный существенный резерв роста > качества софта я вижу в развитии систем Source code analysis. > Остальные резервы уже в основном выбраны ИМХО. Безусловно. Но если уж пошел такой разговор, то и в этом случае резервы невелики. Единственный путь, который не является тупиковым - это сокращение числа фич в одной программе путем разделения больших программ на множество маленьких, но взаимно интегрированных. Причем для того, чтобы непопулярные фичи также были кем-то реализованы необходимо открывать заказчикам исходный код.
	RIK 7 Jun 2006 10:06 AM
>путем разделения больших программ на множество маленьких Это далеко не всегда возможно. Усложнение программ - объективная закономерность. И дальнейшее усложнение возможно только при поддержке source code analysis систем. Такие системы находятся сейчас в зародышевом состоянии, и тем не менее уже дают неплохие результаты.
	Shamlo 7 Jun 2006 1:05 PM
> RIK: Усложнение программ - объективная закономерность. Вздор! Просто такую методологию продавливают разработчики закрытого ПО. Им не хочется документировать множество интерфейсов, которые используются внутри большой закрытой системы. При этом сами они выполнить разработку этой большой системы на должном уровне не могут, но и другим не дают. > Такие системы находятся сейчас в зародышевом состоянии, > и тем не менее уже дают неплохие результаты. Вот про зародышевое состояние - это точно. Не так давно пробовал такую штуку от Parasoft. Она меня удивила до самого костного мозга. Зафиксировала как ошибку сам факт использования оператора "?". Он был использован правильно, но она даже проверять не пыталась, а прямо сказала, что лучше как-то переформулировать код, чтобы облегчить ей задачу по проверке.
	RIK 8 Jun 2006 2:02 AM
>Вздор! Просто такую методологию продавливают разработчики закрытого ПО. Им не хочется документировать множество интерфейсов, которые используются внутри большой закрытой системы. При этом сами они выполнить разработку этой большой системы на должном уровне не могут, но и другим не дают. Глупости говорите. Во-первых, качество современного открытого софта сравнимо с качеством современнрго проприетарного. То есть, говоря вашими словами, ОС-программисты также "выполнить разработку большой системы на должном уровне не могут". А кто может - непонятно. Видимо, вы один. Во-вторых, проприетарные интерфейсы документированы зачастую лучше, чем открытые. Однако документация интерфейсов ставит другую проблему - она должна постоянно поддерживаться в актуальном состоянии. Возможное решение - документация должна динамически генериться соответствующей Source code analysis (SCA) - системой. Еще по поводу SCA-систем. Говоря о "неплохих результатах" я имел в виду не только тулы вроде prefix/prefast, но и системы наподобие SourceInsight.
	Shamlo 8 Jun 2006 8:04 AM
> RIK: Во-первых, качество современного открытого софта сравнимо > с качеством современнрго проприетарного. Это не аргумент в пользу того, что две эти парадигмы равны с точки зрения качества софта. Открытая парадигма на порядок лучше, но... ПРИ ПРОЧИХ РАВНЫХ. Т.е. финансирование должно быть такое же как при разработке софта закрытого. Кроме того, тот факт, что качество открытого софта более менее равно качеству закрытого при относительно слабом финансировании разработки первого, говорит о том, что закрытая парадигма явно хуже с точки зрения затрат. Грубо говоря, зачем платить больше, если можно получить тоже самое дешевле. > Возможное решение - документация должна динамически > генериться соответствующей Source code analysis (SCA) - > системой. Это не просто возможное решение, а единственно возможное. Но только генериться она должна не SCA-системой, а отдельной системой для генерации документации (помните тезис о максимально возможном дроблении функционала?). Кроме того, главное здесь все-таки не то, кто будет генерить, а то, какими будут исходные данные для этой генерации. Перечень прототипов функций нельзя назвать исчерпывающей документацией. К каждой функции еще необходимо написать развернутый комментарий в какой-то стандартной форме, чтобы генератор мог включить его в документацию.
	RIK 13 Jun 2006 6:02 AM
>Открытая парадигма на порядок лучше, но... ПРИ ПРОЧИХ РАВНЫХ. Т.е. финансирование должно быть такое же как при разработке софта закрытого. то есть вы считаете, что дело в финансировании, и стоит только ОСС-программистам дать денег, как они явят чудеса программистского искусства? Так вот - я уверен, не явят. Из достоинств "открытой парадигмы" я вижу только одну - отсутствие жесткого прессинга по срокам реализации (что тоже палка о двух концах - можно при этом оказаться вечно догоняющим). И много недостатков (а именно отсутствие или необязательность многих вещей, которые обязательны в больших программистских фирмах. Например, ответственное code review, обязательное использование верификаторов кода, обязательные автоматические тесты перед чек-ином в VCS, наличие PM в тиме, etc.) >тот факт, что качество открытого софта более менее равно качеству закрытого при относительно слабом финансировании разработки первого, говорит о том, что закрытая парадигма явно хуже с точки зрения затрат. Разумеется, ОС-разработки дешевле. Но нужно иметь в виду, что они в целом проще, чем проприетарный софт. Иными словами - проприетарная модель разработки софта позволяет разрабатывать более сложные системы при аналогичном качестве кода. >Но только генериться она должна не SCA-системой, а отдельной системой для генерации документации Нет, именно SCA-системой. Система генерации докуметации должна понимать, например, ключи компиляции и #ifdef-ы, которые использовальсь при сборке библиотеки. Кроме того, такая система должна дополняться системой, которая отслеживает актуальность комментариев.
	Shamlo 13 Jun 2006 12:06 PM
> RIK: Из достоинств "открытой парадигмы" я вижу только одну - > отсутствие жесткого прессинга по срокам реализации И как именно прессинг по срокам связан с открытой парадигмой разработки? На мой взгляд, никакой связи нет. Просто сейчас открытыми разработками люди занимаются в свободное от основной работы время, поэтому нельзя требовать от них укладываться в жесткие сроки. Если они будут работать в режиме full-time и за деньги, то что помешает им планировать разработку по срокам? Фундаментальным достоинством "открытой парадигмы" является открытый исходный код. Этот фактор способен серьезно повысить качество кода, причем не за счет приложения каких-то дополнительных внешних усилий или применения улучшеных инструментов, а прежде всего в силу своей открытой природы. Во-первых, проблемы, возникающие в процессе эксплуатации, легче диагностировать, так как не нужно строить предположений о внутренней логике ПО, а можно просто открыть и посмотреть. Во-вторых, можно не только диагностировать самостоятельно, но и лечить, не прибегая к помощи разработчиков. Ясное дело, заказчику проще, когда дорабатывают ПО сами разработчики, поэтому разумно предоставить такую услугу за дополнительную плату. При закрытом же подходе у заказчика возможность самостоятельной доработки отсутствует принципиально, что однажды запросто может стать проблемой, если принять во внимание главное узкое место - число разработчиков ограничено, а в сутках всего 8 рабочих часов. И в третьих, когда программист знает, что его код будет общедоступен, код этот уже благодаря этому получается более качественным. Такова человеческая природа. Любые публичные действия производятся человеком более тщательно и обдуманно, ибо никому не хочется стать всеобщим посмешищем. Код будет написан не так "чтобы просто работало", а так "чтобы не было стыдно перед коллегами". > Иными словами - проприетарная модель разработки софта > позволяет разрабатывать более сложные системы при аналогичном > качестве кода. Это далеко не аксиома. Мне кажется, что это свойство является не свойством самой модели, а лишь следствием более мощного финансирования. > Система генерации докуметации должна понимать, например, ключи > компиляции и #ifdef-ы, которые использовальсь при сборке > библиотеки. А что в этом такого? Если система генерации документации извлекает комментарии из исходников, то она просто обязана понимать синтаксис препроцессора, чтобы знать какие участки файла дойдут до компилятора, а какие - нет. > Кроме того, такая система должна дополняться системой, которая > отслеживает актуальность комментариев. Ну если актуальность комментариев в коде еще необходимо отслеживать специальной системой, то это не код с комментариями, а какая-то ботва. На мой взгляд, проблема легко решается на уровне программиста, который сам может удалить ненужные комментарии.
	RIK 14 Jun 2006 3:50 AM
>Просто сейчас открытыми разработками люди занимаются в свободное от основной работы время, поэтому нельзя требовать от них укладываться в жесткие сроки. Да, верно. Но отсутствие жестких сроков делает менее вероятной ситуацию, которая типична на последнем этапе разработки в коммерческих фирмах - "правильно исправить уже не успеваем, поэтому сделаем как быстрее". >Фундаментальным достоинством "открытой парадигмы" является открытый исходный код. Этот фактор способен серьезно повысить качество кода, причем не за счет приложения каких-то дополнительных внешних усилий или применения улучшеных инструментов, а прежде всего в силу своей открытой природы. Каков механизм влияния этой "открытой природы" на качество кода? Для разработчиков проприетарной системы код этой системы также открыт. >Во-первых, проблемы, возникающие в процессе эксплуатации, легче диагностировать, Кому - пользователю? Много ли пользователей при возникновении проблемы лезет копаться в коде? >Во-вторых, можно не только диагностировать самостоятельно, но и лечить, не прибегая к помощи разработчиков. А по-моему, заниматься исправлением ошибок должна фирма-производитель продукта. >При закрытом же подходе у заказчика возможность самостоятельной доработки отсутствует принципиально, что однажды запросто может стать проблемой Это действительно потенциальная проблема (я, например, считаю, что код должен передаваться в public domain спустя некоторое время - скажем, 10 лет), но к качеству кода она не имеет отношения. >И в третьих, когда программист знает, что его код будет общедоступен, код этот уже благодаря этому получается более качественным. Несерьезно. Если я работаю в крупной фирме мой код доступен множеству квалифицированных программистов, чье мнение мне важно. Будет ли этот код опубликован в свободном доступе - уже не принципиально. >Мне кажется, что это свойство является не свойством самой модели, а лишь следствием более мощного финансирования. Я привел примеры вещей, способствующих улучшению качества кода, обязатальных в коммерческой фирме (code review, etc) и необязательных в ОСС-программировании. Это организационные различия, дело тут не в деньгах. >А что в этом такого? Если система генерации документации извлекает комментарии из исходников, то она просто обязана понимать синтаксис препроцессора, чтобы знать какие участки файла дойдут до компилятора, а какие - нет. Ничего "такого" в этом нет. Я просто привел пример показывающий, что система генерации документации должна понимать синтаксис языка программирования, т.е. быть SCA-системой. >Ну если актуальность комментариев в коде еще необходимо отслеживать специальной системой, то это не код с комментариями, а какая-то ботва. На мой взгляд, проблема легко решается на уровне программиста, который сам может удалить ненужные комментарии. Проблема переполнения буфера тоже "легко решается на уровне программиста". Проверка актуальности комментариев должна быть одной из задач системы верификации кода.
	Shamlo 14 Jun 2006 8:49 AM
> RIK: Кому - пользователю? Много ли пользователей при > возникновении проблемы лезет копаться в коде? Даже если будет всего один, кому открытый код поможет, то это уже хорошо. А то, что код открыт, на доходы разработчика никак не повлияет. Просто вам, адептам проприетарной модели, очень сложно понять, что при разработке открытого софта уже написанный код вообще не является товаром. Он является лишь поводом для дальнейшего сотрудничества. > А по-моему, заниматься исправлением ошибок должна фирма- > производитель продукта. Должна. Но только если заказчик будет на этом настаивать. Если же заказчику проще и быстрее исправить ошибку самому, то у него должна быть такая возможность. > Несерьезно. Если я работаю в крупной фирме мой код доступен > множеству квалифицированных программистов, чье мнение мне > важно. Будет ли этот код опубликован в свободном доступе - > уже не принципиально. Я говорю об этом не абстрактно, а с учетом личного опыта. В своей жизни я видел очень много чужого кода. Общая тенденция такова, что закрытый код хуже... в том смысле, что он менее читаем и хуже комментирован. Следовательно, его сложнее изменять, что повышает вероятность появления ошибок. Может причина в чем-то другом, но факт остается фактом, а других возможных причин в голову что-то не приходит. > Я привел примеры вещей, способствующих улучшению качества > кода, обязатальных в коммерческой фирме (code review, etc) и > необязательных в ОСС-программировании. Это организационные > различия, дело тут не в деньгах. Так потому они и являются обязательными и необязательными, что финасирование различное. > Проверка актуальности комментариев должна быть одной из задач > системы верификации кода. Я не понимаю, как это можно автоматизировать. Допустим, я написал вот такой комментарий: /* Копируем данные в свой локальный буфер, чтобы другие потоки могли свободно их изменять, пока мы работаем со своей копией. */ Теперь представим, что через какое-то время этот комментарий перестал быть актуальным. Каким образом можно автоматически отследить его неактуальность?
	RIK 14 Jun 2006 9:48 AM
>Общая тенденция такова, что закрытый код хуже... А мой личный опыт говорит, что _современный_ код, который пишут, например, в МС не хуже (а то и лучше) _современного_ открытого кода. Как раз тенденция обратная - проприетарный код стал заметно лучше за последние 7 лет, а качество открытого кода не изменилось. >Так потому они и являются обязательными и необязательными, что финасирование различное. Не только. Приведенные мной примеры ограничивают свободу программиста - для ОСС это может быть проблемой. >Я не понимаю, как это можно автоматизировать. Понятно, что не удастся проверить, насколько хорошо комментарий описывает функциональность. Однако если описание интерфейсов в комментариях каким-то образом стандартизовано, то можно проверять некоторые вещи. Например, что все параметры функции описаны. Более того, для некоторых параметров можно проверять правильность описания.
	Shamlo 14 Jun 2006 11:35 AM
> RIK: А мой личный опыт говорит, что _современный_ код, который > пишут, например, в МС не хуже (а то и лучше) _современного_ > открытого кода. Очевидно, у вас какие-то другие критерии качества. Для меня критериями качества является хорошая читаемость и исчерпывающие комментарии. Эти свойства позволяют повысить предсказуемость вносимых в код изменений. И именно это наиболее важно, так как только постоянные изменения в коде с целью его функционального улучшения способны служить поистине неиссякаемым источником дохода для разработчика. Быть может, что код, написанный в МС, такими свойствами и обладает, но лично я его не видел. Для меня он абсолютно нечитаем. Изменения я тоже вносить не могу. О каком качестве вообще может идти речь? Строго говоря, никакого кода вообще нет. Есть просто бинарные файлы, которые иногда работают, иногда не работают, а иногда работают, но не так. > Однако если описание интерфейсов в комментариях каким-то > образом стандартизовано, то можно проверять некоторые вещи. Тогда это уже будут не комментарии, а некий мета-язык для описания интерфейсов. Вся прелесть комментариев как раз в том, что они пишутся не везде, а только там, где это необходимо.
	RIK 21 Jun 2006 6:12 AM
>Для меня критериями качества является хорошая читаемость и исчерпывающие комментарии. Хорошая читаемость - да. Комментарии - скорее, нет (хорошо написанный код в комментариях нуждается редко). >Строго говоря, никакого кода вообще нет. Есть просто бинарные файлы Исходники Windows широко доступны: http://www.microsoft.com/resources/sharedsource/Licensing/d efault.mspx Исходники WindowsCE доступны вообще всем: http://msdn.microsoft.com/embedded/usewinemb/ce/sharedsrcco de/cesslp/default.aspx Я уж не говорю про "утекший" код, самплы и хедера в SDK, etc. Вполне достаточно для того, чтобы составить впечатление о коде, который пишут в МС.