- Google предлагает переосмыслить подход к раскрытию информаци..., Аноним, 09:01 , 23-Июл-10 (1) +5
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 09:59 , 23-Июл-10 (7)
> К сожалению работает только full disclosure, посмотрите последние выпуски PHP и Firefox, в PHP поправили дыры о которых приватно сообщили в мае, а в Firefox - в марте. Одновременно в Firefox почти мгновенно поправили дыру о которой стало известно публично.Как вы можете знать, работают ли другие способы, если вы их не видите? В том то и суть, чтобы было больше дела, и меньше зависеть от от пустых крикунов. Своевремменность нахождения и исправления ошибок зависит в первую очередь от качества архитектуры проекта. Если архитектура корявая - потом кричи, не кричи об ошибках - их будет море. Как это можно наблюдать с PHP.
- Google предлагает переосмыслить подход к раскрытию информаци..., klalafuda, 10:16 , 23-Июл-10 (9) –1
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 10:29 , 23-Июл-10 (12) +1
>s/PHP/руками/g > >В руках мастера и палочки - оружие. Обезьяна же на танке безопасна. Да, если выбора не оказалось в конкретный момент. Однако, если выбор есть, то хороший мастер выбирает хороший инструмент. Хотя, я так понял, вы согласны со мной относительно низкого качества PHP. А сравнивать палочки и танк по качеству - нелогично. Вы явно путаете качество с размером и назначением. Могут быть качественные палочки и некачественный танк.
- Google предлагает переосмыслить подход к раскрытию информаци..., klalafuda, 10:44 , 23-Июл-10 (14) –7 [V]
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 11:00 , 23-Июл-10 (19) +4
>Нет, Вы неправильно меня поняли. Я не согласен с Вами по поводу 'низкого качества PHP'. Это точно такой же инструмент, как и все остальные. Perl, Python, Ruby, you name. Ни чем от них не отличающийся. По крайней мере с точки зрения 'качества'. То, что вы ставите в одну линию PHP, Perl, Python и Ruby по качеству архитектуры, может говорить только о том, что вы плохо представляете себе архитектуру ПО и процессы проектирования. >Поясню проще: с умом можно разрабатывать качественные продукты на любом из них. Разрабатывать-то можно, но только не с умом. Продукт может и будет одинакового качества, но себестоимость его производства с помощью инструментов разного качества будет тоже разной. Таких простых вещей не знаете. А еще говорите о компетентности. >Кривыми же руками можно испортить абсолютно все, что угодно. И абстрактное 'качество' приведенного в качестве примера PHP тут совершенно не причем. Не стоит списывать дремучую некомпетентность отдельных конечных пользователей на проблемы инструмента. Поздно метаться. Вы сравнивали до этого по качеству танк и палочки. А ваши поздние оправдания по поводу плохого качества ваших мыслей - сродни тем самым выкрикам о больших количествах найденных и исправленных ошибках, когда качество проектирования было плохим изначально.
- Google предлагает переосмыслить подход к раскрытию информаци..., Crazy Alex, 16:05 , 23-Июл-10 (54)
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 16:36 , 23-Июл-10 (56) +3
>Да понятно, что PHP не без недостатков, но всё же это далеко не бейсик.Ну если вы можете сравнить только с бейсиком - то конечно. >Писать на нём хорошо можно, он этому не мешает особо. Писать и на бумаге хорошо можно, она тоже этому не мешает особо. >Не навязывает - это да, но не мешает. Этим интересным противопоставлением вы как бы пытаетесь нам сказать, что вам даже тех навязываний, которые есть в PHP не достаточно, но зато вас утешает, что он вам "не мешает особо". Вообще очень даже много чего навязывает, как многие более примитивнные языки. Хотя примитивные языки и должны навязывать - стиль, методы решения и др. - в этом их назначение, своеобразная "защита от дурака". Но ведь речь шла именно о качестве реализации, а это совсем другое. Потому что будучи рожденным, как узко-специализированное средство для веб-разработок, PHP пытается изображать из себя язык общего назначения. А в итоге - "не пава, не ворона". И куча хаотичных заплат во внутренней архитектуре. Плюс еще плохое начальное проектирование даже как узко-специализированного средства. И комьюнити такое же. Интересно, на каких тогда языках вам "плохо писать", и какие языки вам "танцевать^W писать мешают"? >Если, конечно, вы не PHP3 имеете в виду, с register_globals, magic quotes, без ООП и пространств имён. Понятно одно. Вы тоже один из тех, кто плохо представляет себе, что такое архитектура ПО и качество проектирования. И руководствуетесь преимущественно такими туманными критериями, как "на нем хорошо писать", типа "хорошо сидим".
- Google предлагает переосмыслить подход к раскрытию информаци..., Аноним, 12:22 , 23-Июл-10 (29) +3
- Google предлагает переосмыслить подход к раскрытию информаци..., Michael Shigorin, 14:04 , 23-Июл-10 (41)
- Google предлагает переосмыслить подход к раскрытию информаци..., User294, 14:30 , 23-Июл-10 (46)
- Google предлагает переосмыслить подход к раскрытию информаци..., XoRe, 20:43 , 23-Июл-10 (72) –2
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 09:59 , 24-Июл-10 (81)
Итак, речь шла о факторах, влияющих на количество багов в проектах и мерах их предотвращения.А "обезьяна" - была метафорой к этому. >>>Обезьяна же на танке безопасна. >> >>А как насчет обезьяны с гранатой? :) > >Ну если рассуждать с научной точки зрения, то вероятность того, что она грамотно оторвет чеку, после этого бросит в вас (и умудрится не подорваться сама) - вероятность маленькая) То есть вы считате, что с научной точки зрения очень мала вероятность того, что примат сможет "грамотно оторвать чеку". Это в метафоре прмерно соответствует способности представителей определенных течений в программировании написать код, который может запускаться. Далее вы видимо считаете, что обезьяна с гранатой да еще и с оторванной чекой по прежнему не представляет большой опастности, и ей по-вашему надо ее еще именно бросить, чтобы создать эффект. А может ли она подорваться сама - это по-вашему вообще не важно. С учетом того, что обезьяна - это метафора какбэ "специалиста", плохо владеющего инструментом, а взрыв - это метафора большого количества багов в проектах, с учетом этого ход ваших рассуждений очень даже характеризует. Особенно игнорирование опасности "самоподрыва". >Хотя смотря какая обезъяна. >Если на вас несется разъяренная горилла, то там пофиг на гранату) И продолжение вашей мысли не менее интересно. Далее, судя по всему, если попытаться вывести общий смысл из ваших сбивчивых формулировок - вы не согласны с тем, что количество багов в первую очередь зависит от качества проектирования. >А с кодингом - 99% ошибок идут изза кривизны рук, и 1% - изза ошибок самого языка. >Я бы даже сказал, что соотношение 99,99% и 0,01% =) >Фишка ещё в том, что когда знаешь, что вон в том модуле, или вон в том операторе часто находят ошибки, можно написать код с оглядкой на это. Интересно, что за такими "языками" вы предпочитаете пользоваться, в операторах которых "часто находят ошибки". И вмето того, чтобы отправить баг репорт об этом, фундаментально огораживают это место большим количеством "проверок". И судя по всему, операторов в них не меньше, чем модулей. >Т.е. поставить там побольше проверок данных, побольше проверок на error=1 и т.д. Т.е. по-вашему, главное поставить "побольше проверок", а проектировать не обязательно. А откуда у вас берутся проверочные условия, вы обычно не особо задумываетесь. А также какова вероятность неправильно поставить сами эти проверки. >Т.е. руками уменьшить даже вероятность глюка изза ошибки языка. >Обычно наоборот - это язык уменьшает вероятность глюка изза кривых рук) Ну и наконец, вы явно путаете понятие языка со средсвами разработки. Из всего вами сказанного, отчетливо виден общий стиль, в котором вы пишете. Это длинные-длинные тексты програм, с большим-большим количеством "проверок". И вы убеждены, что именно такой стиль фундаментально огораживает вас от большого числа багов. А также можно пердположить, что вы пользуетесь средствами, которые такой стиль всячески поощряют, и создают иллюзию, что якобы можно обойтись и без проектирования.
- Google предлагает переосмыслить подход к раскрытию информаци..., Аноним, 10:23 , 23-Июл-10 (10)
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 10:34 , 23-Июл-10 (13) –1
>Почему не вижу ?Потому что у вас упрощенный и идеализированный взгляд на мир. >Не вижу только до выхода исправленной версии. Как только версия вышла обычно можно отследить историю определения дыр. И в самих advisory обычно приводится лог, дыра найдена тогда-то, тогда-то сообщено разработчикам, тогда-то поправлено, тогда-то информация придана огласке. А кто вам сказал, что все придается огласке? Если цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 15:19 , 23-Июл-10 (50)
>> Если цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.^Есть^ цивилизованный способ сообщать об ошибках разработчикам, не придавая ошибки огласке. Тем не менее все довольны.
- Google предлагает переосмыслить подход к раскрытию информаци..., XoRe, 14:28 , 24-Июл-10 (85)
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 15:10 , 24-Июл-10 (88)
>Ну и плюс, не просто сотрясать воздух фразами "грамотное проектирование", "семантическая ошибка", и т.д. >А добавить конкретики.Я вообще-то говорил о зависимости количества багов от качества проектирования. А не сферическое "грамотное проектирование" в вакууме. То есть для вас тема проектирования - не конкретна? Сдается, что вы вообще плохо представляете себе, что это такое. Вы не знаете, что такое "семантическая ошибка"? А это вы вообще к чему? >Например, привести пример кода или пример проектирования, который доказывает вашу правоту. Интересно, как вы представляете себе пример проектирования, размещенный здесь в форуме? И что я потеряю, если факт моей правоты, конкретно вы посчитаете не доказанным? >Ещё можно ссылки приводить на конкретные статьи. На какие статьи? В уголовном кодексе? Как я могу привести ссылки на конкретнные стаьи, если я на конкретные стаьи не ссылался? Вы обнаружили пробелы в своих знаниях, и хотите, чтобы я вам подсказал, как их восполнить? При этом ставя ворос так, как будто я обязан заботиться о целостности ваших познаний. >А то получается спор в виде "все вот так и вот так, а если вы не понимаете этого, то вы дилетант и дурак". Я что-то потеряю, если у вас так получится? Я говорил то, что я говорил. Количество багов в проектах в первую очередь зависит от качества проектирования.
- Google предлагает переосмыслить подход к раскрытию информаци..., User294, 14:32 , 23-Июл-10 (47) +2
- Google предлагает переосмыслить подход к раскрытию информаци..., klalafuda, 09:16 , 23-Июл-10 (2)
- Google предлагает переосмыслить подход к раскрытию информаци..., klalafuda, 09:19 , 23-Июл-10 (3)
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 13:08 , 23-Июл-10 (35) +1
> Дело за малым: заставить пользователей конкретного продукта в массовом порядке своевременно накатывать соответствующие обновления безопасности. Иначе это все борьба с ветряными мельницами.И в чем суть вашего сарказма? Вы описали то, что существует, так, какбудто этого нет. Ну можно не заствлять своевременно накатывать - есть автоматическое обновление безопасности. Да, оно работает не идеально. Но не хуже, чем лавинообразный процесс исправления ошибок, как результат плохого проектирования. >PS: Да, и, если уж ставить себе глобальную задачу бороться за мир во всем мире, отучить пользователей качать всякую дрянь из сети. В противном случае, не смотря на все потуги, конечный результат будет все равно один и тот же. А интересует лишь конечный результат. Все гораздо проще. Есть разработчики, которые плохо проектируют, и есть пользователи, которые с завидным упорством выбирают плохие разработки. И таких большинство. А есть качественные проекты. И есть пользователи, которые такие проекты умеют отличать. И таких всегда меньшинство. Однако польза от более качественного меньшинства всегда компенсирует проблемы, которые порождает большинство. В этом заключается природное рановесие. Все в конечном итоге определяется качеством проектирования, а во вторую - системой исправления ошибок. А там, где проекты качественнее - там и система исправления ошибок качественнее, как следствие, а не наоборот, как причина, потому что систему исправления ошибок тоже надо проектировать. Просто в качественных проектах меньше шума об исправленных ошибках. Так же, как и криков о борьбе за мир там, где друг с другом не борются.
- Google предлагает переосмыслить подход к раскрытию информаци..., klalafuda, 15:26 , 23-Июл-10 (52) –1
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 15:41 , 23-Июл-10 (53)
>Применительно конкретно к браузерам этого нет.Чего именно _этого_ нет? "И как один умрем в борьбе за _это_". >Достаточно взглянуть на статы user agent на пачке веб серверов с более-менее приличным трафиком. Зоопарк из версий осла и фокса фееричен. А ведь все помнят, что если не каждый то через раз то точно релиз фокса закрывает иногда до десяти критических дыр, которые при определенном желании и навыке могут привести к компрометации системы. И дыры, кстати, после релиза (а иногда и до) становятся известными широкой публике. >Да, они - закрыли. Они - молодцы. Да, у них есть соотв. механизм обновления. Причем в MS Windows например нужно приложить минимум телодвижений, чтобы фокс был up to date. А что толку? Если хотя бы треть их пользователей воспользуется обновлением а тем более сделает это своевременно - это уже можно сказать счастье. Ну а остальные? Вы, собственно что здесь доказываете? Что механизм автообновлений работает не идеально? Ну так я уже выше это и так сказал. Кроме того, я уже сказал, что лучший способ минимизировать количество дыр - качественное проектирование. А вы опять все про дыры, да про дыры. Вы за что боритесь-то? Кроме невнятных формулировок, изобилующих всякими словечками, смысл которых, как видно, вы плохо понимаете, вам так и не удалось сформулировать, за что и против чего вы выступаете. Ясно только одно - что вы плохо представляете себе реальные процессы разработок.
- Google предлагает переосмыслить подход к раскрытию информаци..., klalafuda, 16:14 , 23-Июл-10 (55) –1
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 17:16 , 23-Июл-10 (58)
В исходном посте вы говорили так, как будто автообновления вообще не существует. Поняв эту оплошность, вы теперь пытаетесь что-то такое выдумать на эту тему.>Неидеально - это как бы это сказать, это несколько смазано. Я бы сказал чуть точнее что он не работает вообще. В лучшем случае - присутствует в следовых количествах. Без этого ключевого момента все попытки оптимизации процесса репортирования багов - это все равно что тушить пожар из кружки. Круто, громко, в принципе может дать красивый PR при должном подходе, но... вот только это мало полезно с практической точки зрения. Во-первых, вы путаете автообновление с "процессом репортирования багов" - что в очередной раз демонстрирует, что вы плохо знаете, о чем говорите. "присутствует в следовых количествах" - Такое впечатление, что вы просто переводите малопонятные вам английский тексты авто-переводчиками, пытаясь скрыть свою некомпетентность за всякими словечками. Ну если вы пользуетесь только софтом с большим количеством дыр и не можете настроить автообновление, то это еще ведь не значит, что у всех так. Хотя то, что автообновление - вещь неидеальная, я уже сказал. Но если у вас совсем с этим плохо, то это уже сугубо ваши проблемы. >> Кроме того, я уже сказал, что лучший способ минимизировать количество дыр - качественное проектирование. > >Есть какие-то конкретные предложения? Кроме абстрактного пожелания 'давайте будем писать лучше'? Вы хотите сказать, что не знаете, как это делать, или вы просто не верите, что где-то это делают. Ну это не удивительно, если вы понимаете "качественное проектирование" просто как "лучше писать". А зачем мне предлагать, если качественно проектируемые проекты и так существуют. Другой вопрос, что это вы сомневаетесь в их существовании. Но это уже не моя проблема. >Если же обсуждать сугубо по абстракциям лежа на диване и плюя в потолок то я бы предложил, чтобы все человеки на земле были добрыми честными умными и вообще положительными во всех отношениях. Мечтать всего лишь о 'качественном проектировании' - это как-то слишком мелко. Нужно шире смотреть на проблему. Не нужно себя ограничивать в мечтах. Ну я понял уже, что вы считаете, что качественного проектирования по-вашему в принципе в природе не существует. Вы считаете это чем-то абстратным, а любые упоминания об этом, вызывают у вас ассоциации с "борьбой за мир". Похоже, что вы плохо представляете, что такое проектирование вообще. >Борюсь? Нет, спасибо. Пусть уж гугл сам как-нибудь, без меня. Благо они большие красивые и толстые и вроде как все могут. По крайней мере по слухам. У них все получится рано или поздно. Хотя сам подход конечно же не может вызывать некоторых сомнений. О чем и было написано мною выше. Впрочем, это их бизнес, их продукт и соответственно их проблемы. И все-таки вы за что-то тут боритесь, только не можете сформулировать за что конкретно и прыгаете с тему на тему. >Хотя.. Они несут определенную социальную ответственность. И микрософт и мозила и теперь уже гугл. Ведь это в первую очередь благодаря их продуктам Сеть постепенно но неумолимо превращается в один большой ботнет катастрофических размеров. И с них - спрос. А, понятно, вас беспокоит социальная ответственность. Именно поэтому вы отождествляете вопросы исправления багов с идеями борьбы за мир. Правда, судя по вашим словам, вам и то и другое кажется безнадежным, но все равно вы призываете к социальной ответственности за это безнадежное дело. Такое ощущение, что вас вообще раздражает развитие индустрии ИТ. Без всего этого вам явно было бы проще жить, и вам бы очень хотелось вернуться во времена, когда этого всего не было. >Упорно хотите перейти на личности? Welcome to LOR. Здесь я сраться на столь низком уровне не хочу. А, ну да, вы признаете только такую возвышенную полемику, как измерение "длины палочек" и сопоставление этого с танком. (См. в постах выше)
- Google предлагает переосмыслить подход к раскрытию информаци..., klalafuda, 17:44 , 23-Июл-10 (59)
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 18:14 , 23-Июл-10 (62)
>Повторю свой вопрос: у Вас будут какие-то конкретные технические предложенияЕсли вы хотите услышать конкретные технические предложения, сформулируйте ваши вопросы так, чтобы было понятно, что вы разбираетесь в этой технической области. А вас вообще, почему интересует этот вопрос? Вы сами хотите им что-то предложить, но не знаете что? Или вы осознали (или сразу понимали но пытались скрыть) недостаток своих знаний в этой области, и ждете от меня идей, как этот недостаток поправить? >по улучшению архитектуры вполне конкретных проектов - Хрома (если уж новость о гугле) и Фокса дабы уменьшить поток багов в этих проектах и повысить безопасность конечных пользователей? И жалуясь на мою якобы "абстрактность", вы считаете этот свой вопрос конкретным? С учетом масштабов указанных вами проектов и количества используемых в них технологий. И наконец, с учетом этой же масштабности, вы ведь не доказали, что именно в этих проектах с количеством багов все так уж совсем плохо. И то, что один "грамотей" поставил их в один ряд с PHP, а вы это приняли как должное, в очередной раз подтверждает, что вы плохо в этом разбираетесь. >Если Вы так упорно апеллируете к правильной архитектуре то, очевидно, есть какие-то конкретные мысли, предложения, пожелания, может быть даже решения? Ведь нельзя же апеллировать к ней просто так, абстрактно, правда? Я уже прекрасно понял, что для вас зависимость количества багов от архитектуры и качества проектирования - вещь совершенно абстрактная.
- Google предлагает переосмыслить подход к раскрытию информаци..., koblin, 09:23 , 23-Июл-10 (4) –13 [V]
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 10:05 , 23-Июл-10 (8) +1
>Желание гугла понятно - иметь неограниченно большое время на исправление уязвимостей, чтобы никуда не торопясь попивая мохито пол года писать патч.Желание создателей и владельцев Гугла - максимально извлекать выгоду, благодаря своим талантам и способностям. Никуда не торопясь. Это их право и заслуга. > Только причем тут интересы пользователей?! Ну может интересы нормальных пользователей и при чем, а вот интересы всяких бездарностей, которые даже из халявы выгоду для себя извлечь не могут, и просто точат лясы от зависти к другим, вместо того, чтобы самим развиваться - их интересы действительно ни при чем.
- Google предлагает переосмыслить подход к раскрытию информаци..., Lain_13, 10:59 , 23-Июл-10 (18) +4
- Google предлагает переосмыслить подход к раскрытию информаци..., filosofem, 09:29 , 23-Июл-10 (5) –2
- Google предлагает переосмыслить подход к раскрытию информаци..., Аноним, 09:40 , 23-Июл-10 (6) +3
- Google предлагает переосмыслить подход к раскрытию информаци..., SaveMeGood, 10:58 , 23-Июл-10 (16) +2
- Google предлагает переосмыслить подход к раскрытию информаци..., Maris, 11:09 , 23-Июл-10 (21) +3
- Google предлагает переосмыслить подход к раскрытию информаци..., i, 11:40 , 23-Июл-10 (27) –1
- Google предлагает переосмыслить подход к раскрытию информаци..., Аноним, 12:28 , 23-Июл-10 (30) +2
- Google предлагает переосмыслить подход к раскрытию информаци..., i, 12:41 , 23-Июл-10 (31) –1
- Google предлагает переосмыслить подход к раскрытию информаци..., Lain_13, 12:54 , 23-Июл-10 (32) +3
- Google предлагает переосмыслить подход к раскрытию информаци..., fr0ster, 13:36 , 23-Июл-10 (38)
- Google предлагает переосмыслить подход к раскрытию информаци..., XoRe, 14:24 , 24-Июл-10 (84) +1
- Google предлагает переосмыслить подход к раскрытию информаци..., nuclight, 00:10 , 26-Июл-10 (94)
- Google предлагает переосмыслить подход к раскрытию информаци..., XoRe, 17:26 , 26-Июл-10 (101)
- Google предлагает переосмыслить подход к раскрытию информаци..., Andrey Mitrofanov, 18:36 , 26-Июл-10 (102)
- Google предлагает переосмыслить подход к раскрытию информаци..., ВДНХ, 10:30 , 27-Июл-10 (114)
>Скажите это крупным корпорациям. >"Юзайте программы типа echo, cat, grep, head, tail через конвейер" =) >В некоторых случаях программы сложны и огромны не от скуки программистов. >Уточняю: не во всех случаях, а в некоторых. Да, считающему себя программистом обычно скучать некогда, если других способов борьбы с ошибками он не знает, кроме как вставлять в код "побольше проверок", не задумываясь даже толком, откуда он сам берет условия для этих проверок. В результате даже для элементарных вещей у него получается длинный-длинный код, который он уже сам потом с трудом отлаживает. Зато такую работу вместо компьютера он считает "трудолюбием". См. в начале темы.
- Google предлагает переосмыслить подход к раскрытию информаци..., Аноним, 13:14 , 23-Июл-10 (37)
- Google предлагает переосмыслить подход к раскрытию информаци..., uldus, 13:36 , 23-Июл-10 (39)
- Google предлагает переосмыслить подход к раскрытию информаци..., Аноним, 17:47 , 23-Июл-10 (61) –1
- Google предлагает переосмыслить подход к раскрытию информаци..., XoRe, 20:54 , 23-Июл-10 (74) –1
|