Comments 118
Если написанная программа сработала "правильно", то это значит, что во время ее работы выполнилось четное число ошибок.
Баг связан с фичей версии 2.х, в 1.х такого нету. Если бы в процессе прикручивания очередной свистелки подумали бы о нестандартном использовании - то проблема была бы только у пользователей, явно включивших эту фишку.
Самой популярной версии 1.8ххх?
Открытый софт не более безопасный, а *потенциально* более безопасный.
Более того, искать баги будут те, кто в этом заинтересован. А это - разработчики и преступники. Причем, про разработчиков (имею ввиду не конкретно девелоперов, а в целом бизнес) правильно отметили, что они больше заинтересованы в фичах и всяких свистелках, потому что это генерирует денежный поток. Исправление же ошибок всегда менее важно, особенно если эти ошибки не сразу заметны.
Остаются преступники, которые заинтересованы в поиске уязвимостей и совершенно не заинтересованы в их исправлении, по понятным причинам.
Кто остаётся? Энтузиасты? Да, они могут находить баги, но всё упирается в п.1 - желание разработчиков заниматься этими тикетами. Есть и ещё несколько "бонусов": чтобы находить ошибки, нужно обладать знаниями и опытом чуть выше среднего (в противном случае их бы исправляли ещё до релиза); ещё больше знаний, опыта и времени требуется чтобы найденный баг воспроизвести (поймать) и исправить. И зачастую как раз времени не хватает, т.к. сами девелоперы загружены требованиями бизнеса выкатить новые фичи и без того фантастически быстро.
Так мы приходим к интересной ситуации: да, открытый код может просмотреть и в теории исправить большее количество людей. но с другой: бОльшими для этого ресурсами обладают как раз крупные компании, а они открывать код до сих пор не очень любят.
-
В завершение вспомню эпизод из собственного прошлого, когда начальник мне втолковывал, что рабочее время необходимо тратить на код, "привносящий ценность продукта для клиента", а рефакторингом и мелкими улучшениями я могу заниматься в свободное время бесплатно, если у меня есть такое желание. Хорошо, что ему не пришла мысль штрафовать за баги, но я не стал этого дожидаться и ушёл из компании.
Случай может показаться надуманным, но он правдив, и хотя (к счастью) таких заявлений я больше не слышал, он показывает общее стремление бизнеса и объясняет, почему софт настолько забагован, а ошибки не исправляются независимо от открытости кода.
Ну собственно начальник прав, программа нужна чтобы нести ценность клиенту.
Про "писать в свободное время", это он про расстановку приоритетов (компания платит не за идеальный код, а за такой, который устраивает клиента), его не надо буквально понимать -)
Представьте мир, в котором поиск в интернете выполнялся бы, ну хотя бы за минуту, а ещё лучше за 10 минут, а не за 0.1сек.
Лучше сутки. Мир был бы прекрасен. Люди не искали бы всякую чушь, и не тратили бы время на чтение буллшита и покупку всякой ненужной дряни. Было бы меньше гугл-специалистов, которые без интернета под рукой не могут ничего выполнить, и больше реальных специалистов с твердыми знаниями. А кому надо что-то поискать по делу, могли бы заранее записывать свои запросы в блокнот, расставлять приоритеты, вычеркивать лишнее.
Такие времена уже были - когда компьютер не умещался у вас в кармане, а занимал целое здание. Когда отлаживать программу приходилось не в удобной IDE пошагово, а (в уме) на листочке, затем регистрироваться на доступ к компьютеру, и на следующий день приходить проверять - сработало или нет. Если нет - то снова думай, почему, и запись на следующий день. Причем программа выполняется примерно тот часовой промежуток времени, на который ты регистрировался. Т.е., запустил вычисления - жди, через час тебе результат, иди домой думай.
И в этом не было ничего прекрасного - ту программу, которую сегодня может за полчаса написать вчерашний студент, писали единичные профессионалы месяцами; результаты достигались не просто нервами, а потом и почти кровью. Но - чуши меньше не было, просто она была оффлайн - в кафе, на улицах, домашних кухнях.
Спасибо Интернету и в целом техническому прогрессу за то, что мне не нужно учить в самом деле чушь - таблицы чисел с точностью до 8 знака после запятой, названия функций и порядок параметров, тонкости различий процессоров и т.д., а могу заняться именно тем, чем мне нравится заниматься - созданием софта, который работает приемлемо неплохо.
И раз в десять запросов выдавал бы мусорный ответ.
Ну сейчас он 9 раз из 10 выдает мусорный ответ. В итоге таже минута на поиск и получается (на самом деле гораздо больше)
Я думаю, это от порядка величин зависит. Если на одну попытку будет уходить минута, ничего страшного, переживем. Врядли чтото сильно изменится. Если 10 минут - то уже да, сильно хуже
Ну вот сейчас я попробовал на старом телефоне (которым только бросил пользоваться) выполнить свой стандартный путь "найти что-нибудь": разблокировать экран, запустить wifi, открыть браузер, ввести запрос, дождаться загрузки. На это у меня ушло 36 секунд. Всего в 2 раза меньше минуты. А мне это приходилось делать каждый раз, когда хотелось чтонибудь найти, и я этого даже не замечал
каждый очередной запрос, например уточняющий запрос
Как правило, на какой-то итерации я обычно бросал это дело и садился за комп. Но скорее не из-за долгого отклика чего либо, а из-за моей неспособности набирать что либо на мобильной клавиатуре.
Но у меня есть и опыт пользования компьютером в детстве, когда инет был очень медленным (уж не знаю, насколько, но точно медленнее чем сейчас). И привычки формируются быстро - например, открыть сразу несколько вкладок с результатами поиска, и пока читаешь одну, остальные уже догрузятся
Зная, что поиск займет "36 секунд" вы заранее отфильтровываете "ерунду", которая не стоит того, чтобы тратить на неё столько времени
Видимо у нас и правда разные паттерны использования интернета. Я и сейчас, с быстрым интернетом, всегда фильтрую "ерунду", и ни разу не гуглил что такое харамамбура, даже сейчас, представьте, не хочу. Так что может быть я и вправду намного легче переживу резкое замедление интернета, в отличие например от вас
Представьте мир, в котором поиск в интернете выполнялся бы, ну хотя бы за минуту, а ещё лучше за 10 минут, а не за 0.1сек.
Есть такой мир, Марсом называется.
А если из-за багов программа ещё и уносит ценности клиентов налево?
Хотя понятно что это будет проблема клиента и юристов а не начальника.
Клиент заведет тикет, баг исправят.
Программист, устраняя баг из тикета, будет нести пользу бизнесу.
Здесь все-таки надо правильно акценты расставить, не что баги - это хорошо, не что плохой код - это хорошо, а что в оплачиваемое время работнику надо работать то, что от него работодатель хочет, а не то, что работнику кажется важным, а работодателю не важным.
Что хочет работодатель - доносит менеджер проекта или начальник, если такая иерархия.
Клиент заведет тикет, баг исправят.При этом:
- Клиент будет вынужден потратить свое время на заведение тикета, хотя изначально на это не рассчитывал.
- Клиент будет вынужден ждать выхода исправления. Кроме того, не все баги удается исправить корректно с первого раза.
- Пара-тройка таких тикетов, и репутация Вашей компании/продукта в глазах клиентов будет основательно подорвана.
Программист, устраняя баг из тикета, будет нести пользу бизнесу.Программист принесет еще больше пользы, если вместо того чтобы постоянно отвлекаться на тикеты, он будет заниматься новым функционалом. Ибо давно и многократно доказано, что Task switching is a costly process.
Здесь видимо каждый о своём.
Проекты, в которых 3 ошибки - это много и повод отказаться от подрядчика - это какие-то микропроекты.
Когда деваться некуда, приходится выбирать лучшее из худшего. И допиливать по ходу пьесы, как в Вашем примере. Тут вопросов нет.
Разговор изначально был о том, что квалифицированный программист сразу пишет идеальный код, и закладывать рабочее время на исполнение технического долга - нельзя, это трата впустую. Ну а если ты не можешь предусмотреть сразу все возможные сценарии, ошибаешься и т.д. - ты плохой программист, трать нерабочее время на свои (что может быть чужие и т.д. - не рассматривается) косяки.
Ну т.е. да, до штрафов исполнителей за баги там было недалеко.
И это не расстановка приоритетов, это вынесение задач за рамки. И я очень рад, что в основном бизнес (уже?) не представляет себе радужных пони, а понимает, что это нормально, что программы могут содержать ошибки и на их выявление и устранение нужно закладывать время и деньги.
Это какой-то странный бизнес. В нем поди и тестировщиков нет, раз у программистов сразу идеальный код?)
Дайте-ка вспомнить. Это было давно, около 9 лет назад, да и проработал я там всего полгода... Но, по-моему, да, у них и тестировщиков не было - каждый программист нёс персональную ответственность за свой участок кода. Т.е. кто последний правил - тот и обязан проверить на идеальность, а заодно не внести собственных ошибок.
А как же энтузиасты, которые не просто находят баги, а ещё исправляют их самостоятельно и отправляют разработчикам патчи? У меня как раз именно так и происходит, одна часть жалоб от простых пользователей, которые тупо нашли баг, но исправить не могут, или даже не знают её причины; и другая часть - те, кто присылает мне патч с исправлением и объяснением причин бага. С первой частью разработчики чинят ошибки в зависимости от настроения и приоритетов, а со второй частью разработчики даже спасибо говорят, если всё сделано всё чётко и качественно (ага, потому что сразу на блюдечке подали готовый результат, остаётся только заценить и принять или отправить лесом).
Возьмем, например, bullet. Там куча готовых к мерджу пулл реквестов висит больше 2 лет, а мейнтейнерам и дела нет.
Я лично тут в одну мелкую тулзину 3 ПР оформил на критические баги, и они уже больше месяца висят, но там это пет-проект одного человека, и я готов понять, почему у него нет времени.
И вот в этом есть плюс открытого софта - можно его форкнуть, подправить баги, добавить фичи и поддерживать самостоятельно. Конечно, если и вам это надоест, но пользователям вашего форка будет больно, но, будем надеяться, найдётся другой неутомимый специалист, который форкнет ваш проект и продолжит поддержку.
Ну это ещё смотря по какой причине и как форк бы создан: или форк был создан, чтобы продолжить разработку брошенного проекта (воскресить его) (первое, что пришло в голову, это проект TrueCrypt, который был внезапно похоронен своими создателями, и который продолжил жизнь как VeraCrypt); либо чтобы сделать альтернативное решение, но базированное на первоначальном варианте (как пример, мой проект libADLMIDI, который я создал на основе adlmidi от Bisqwit. В результате, мой проект значительно отличается от оригинала и имеет значительно более широкий функционал и более качественную работу, хоть и сохраняет остатки первозданного ядра оригинального adlmidi, которых я мал по малу выпиливаю); либо песочница для собственных костылей и для себя; либо конкретно, чтобы вкладываться в оригинал.
Открытый софт не более безопасный, а *потенциально* более безопасный.
Он и потенциально и реально более безопасный.
Просто если в коммерческом софте ошибки встречаются, условно, по штуке на тысячу строк, то в опен-сорсе — штука на десять тысяч строк.
Но и там и там уязвимостей — вагон и маленькая тележка.
У меня был подобный начальник, когда еще был совсем зелёный. Тоже много прикалывался, подшучивал, душевный человек, но Team Lead из него такой себе - кормил директора завтраками, а ни одного прототипа за целый год не сделал.
С опытом повзрослевше понимаешь, что не всё нужно доносить таким начальникам, некоторые лучше понимают на контрасте, когда неожидано для себя замечают, кого они упустили. И умоляют вернуться обратно - часто это путь к гарантированному повышению, и договорится с ними по работе команды значительно проще после таких кейсов.
Всё это к тому, что не всё в этом мире делается так однобоко. Нужно понимать, что однажды на месте этих самых "руководителей" окажешься ты сам.
а если делать рефакторинг во время работы над задачей приносящей ценность клиенту?
Прямой путь к постоянному регрессу. И с QA быстро отношения испортятся. Они взяли на проверку кейс А, а вы попутно нарефакторили еще и кейсы В и С, на которые ресурсы никто не выделял.
Было в практике такое. Сразу вопросы в стиле "а чего так медленно?" со всеми санкциями.
Откровенно говоря, однажды меня так уволили за "профнепригодность". Наняли как Java-разработчика, а посадили на Javascript (который тогда я ещё не знал, это сейчас я могу хвастаться умным словом фуллстек), дали задачу, который я делал одновременно с изучением и языка и фреймворка и всех подводных камней, потом постоянно требовали переделать, а через неделю "забыли", что я только учусь и что вместо одного я делал несколько вариантов и с аргументом "на двухчасовую фичу потратил неделю??" распрощались. Я даже сопротивляться не стал, поскольку с моей стороны также хватило (например, там не пользовались никакой версионной системой, а девелопили напрямую в тест - спасибо, не прод; или переводы делали прямо на клиенте гуглотренслейтом пока в гугле не забанили)
Поэтому сразу видно, кто начальник ("исполнять!") и лидер. Поэтому важны честные диалоги, а не ухищрения (с любой из сторон)
Надо заметить, что в закрытых проектах ошибки те же, только их еще и нельзя увидеть ...
Но это не значит, что возможность их видеть, так уж сильно влияет на качество.
Это влияет на Ваше знание об этом качестве. И, соответственно, на Ваше знание о том, с чем Вам в процессе пользования продуктом придётся столкнуться — и, соответственно, на желание этим продуктом вообще пользоваться.
Когда я (в процессе ремонта) узнал, что кронштейны жалюзи в купленной мной квартире прикреплены при помощи не шурупов, а термопластичного клея; прокладка в кране, который в теории должен перекрывать воду к умывальнику, не садится полностью в седло; а трубка, которая подаёт водопроводную воду в холодильник (для изготовления ледяных кубиков) вообще непонятно куда подсоединена и как перекрывается (но вода из неё продолжает течь), стены дома узнали много новых матерных слов.
Та же фигня и с программными продуктами.
Уточню: юридическая возможность, т.е. лицензия.
Т.е. в принципе возможно пропатчить бинарники (и я этим занимался, т.к. приходилось использовать стороннее решение, забагованное по самое небалуйся, но разраб исходники принципиально не хотел давать, а документация сводилась к "спроси у кого-то из разрабов"), но насколько хорошо и правильно ты это сделаешь, никто не гарантирует, как не гарантирует и отсутствие судебных исков.
Не уверен что там (в log4j) вообще баг был. Кажется, исходно он как фича задумывался, пока его эксплуатировать не начали.
Потому что например в похожих API к примеру, можно написать "${expression}", но нельзя этот ${expression} интерпретировать просто так из переменной. Ну т.е. выражение — фича времени «компиляции» или времени конфигурирования, но в рантайме их формировать нельзя.
А как узнать, "оттуда" класс вызван или не "оттуда"? В логгере-то? Который по дизайну должен быть суперуниверсальным.
Ну т.е. если у меня в конфиге log4j написано ${jndi:...}, то я ССЗБ, но я знаю, что я делаю, а если такое не написано (конфиги-то свои я могу проанализировать, надеюсь) — то в этих условиях он вызываться не должен вообще.
Те редкие люди, которые его реально применяли, вполне могут и доработать свое приложение. А остальные — кто его в глаза не видел никогда, просто его вырубят, чтобы он ничего не делал, не лазал на внешние хосты непонятно зачем, и все такое.
Логгер — он супер универсальный только в отрыве от конкретного приложения. В рамках же приложения вы вполне можете контролировать, что он будет логировать.
Разница в том, что фичу делали намеренно. Её же, блин, вообще можно параметром командной строки отключить!
Вот-вот, баг именно в требованиях. Про это я и пишу.
Думаю, баг в том, что не подумали, что в такое закрытое, как логи, можно протащить что-то извне. Да, сработал принцип "не доверяй внешним данным", да, можно было отключить, использовать проверки и песочницы, но по идее, в логи ничто не должно попадать "извне" и тем более не должно отдаваться наружу.
Честно говоря, мне всё ещё кажется несколько странным фильтровать и не выводить некоторые данные в лог, такие, как номера кредиток, заменяя их звездочками (для понимания поясню, например, замена регулярками)...
Проприетарный софт обычно продают. И если баги вылезают у клиента, то разработчиков дрючат, и соответственно над "выявленными" багами работают.
Условно можно разделить работу над багами по следующим критериям: выявляемость и исправляемость.
В проприетарном софте баги выявляются тестировщиками и пользователями, исправляются разработчиками в силу обязательств возникших при продаже.
В опенсурсном софте баги могут выявить другие программисты, которые условно и являются пользователями и тестировщиками, и это если ошибка возникнет уже у их пользователей, или же программисты-пользователи таки найдут ресурсы для чтения и анализа исходников, а изначальные программисты могут даже выявленные ошибки не исправлять поскольку у них может не быть заинтересованности, да и обязательства у них лишь моральные.
Баги будут в любом софте в силу человеческой природы. А вот от формы распространения софта отношение к багам уже отличается. Однако это различное "отношение" совсем никак не коррелирует с количеством "выявленных" и "исправленных" багов.
>> 1000 глаз, которые не хотят проверять код открытых проектов
Интересно, как бы их проверил@Andrey2008, будь бы их исходники коммерческой тайной за семью печатями.
А то, что пистон надо вставлять тому, кто решает, какому багу приоритет отдавать.
Вопрос, наверное еще и в том, что разработка за 35 лет шагнула далеко вперёд и это уже не интивидуальный процес свободного художника, как в лохматом 1985, а коллективный индустриальный труд. На тысячу глаз нужны сотня кошельков и десяток рук. И структура с невысокими накладными расходами, которая свяжет их во едино.
По моему опыту, любые мейнтейнеры куда больше любят патчи, чем баги. Когда уже есть разумный патч, мейнтейнеры особо не сопротивляются его включению в основную ветку. Это я к чему - вместо открытия issue "а тут у вас memset" попробуйте предложить сразу исправление в виде pull request на GitHub или там патч в Gerrit. Мейнтейнеры открытых проектов работают над ними в свое свободное время за бесплатно, уважайте их труд.
Очень смелое утверждение про время и бесплатность. Доказательств у вас, конечно же, есть достаточно?
Есть определённая статистика, да.
Ну вот я, например, мейнтейнер свободного проекта и делаю это бесплатно, в свободное время. И это не фигура речи.
Хм, ну отчего же. Проверить и принять патч куда менее трудоёмко, чем самостоятельно выяснять и исправлять. Наверное, лучше, когда своё время и деньги потратит другой, и по "доброте душевной" предложит готовое решение, которое от вас не будет стоить почти ничего.
Есть личный опыт. Процентов 90 коллег по этому (международному) проекту были именно "в свое свободное время и за бесплатно". Остальные имели либо гранты, либо пожертвования, но все же имели основную работу, и только единицы были full-time.
Никогда не мог читать эту фразу иначе, как "уважайте меня за то что я делаю хрень".
Нет.
Терпеть, сожительствовать и принимать - да. Уважать - нет.
Эта фраза пахнет оголтелым коммунизмом из капиталистических страшилок 50-60 годов, где есть некий вася, который ничего не может, но претендует на такие же блага (в данном случае уважение) как некий петя, который может и умеет.
Если петя может и умеет, то что ж не делает? Пока от пети вместо дел одни претензии к васе, который что-то делает и дает пете пользоваться сделанным бесплатно и без ограничений.
Это строится на 2х допущениях.
Вася делает то, что кому-то нужено.
Петя этим пользуется.
Samba - это весьма популярный проект, я бы сказал. Это как с OpenSSL - пользуются буквально все, а после истории с heartbleed оказалось что делают его три с половиной человека на $2K пожертвований в год, какая неожиданность. И рассказчики про вась с петями немедленно нарисовались, а как же.
Что поделать... За добро, конечно, большинство. Но зло лучше организовано...
Интересно, а эти три с половиной человека пытались привлечь побольше народу? Ну хотя бы объявление вывесить на главной сайта и в Readme? Или как никто не ругал, так грудь колесом, а как пальцем тыкнули, так сразу я не я и вообще пилите сами?
И тем не менее уже готовые PR даже всего в одну строчку висят годами, даже уже зааппрувленные людьми с правами мерджить (и это не единичный пример). Вот, кстати, завтра как раз годовщина, надо опять пингануть. Вы вот правильно сказали, что уважать можно за труд, только вот что-то этого труда-то и нет...
вот да. открытый код - вообще не про "твори добро по всей земле - да еще 1000 глаз вам в помощь". Это вообще про другое - уменьшение рисков "смерти" мейнтейнера, внедрение открытых решений в существующий бизнес с в общем-то простой целью заработать впоследствии на его саппорте и/или подписке. В общем что-то сродни пиратских копий аудиокассет/дисков в 90х - потом просто собирать с концертов. Не понятно почему у автора пригорает.
Кстати, да, спасибо. Открытостью решается именно тупиковая в закрытом софте ситуация "собаки на сене", когда софт или умер (разрабы забросили, обанкротились и т.д.) или зомби(софт вроде бы под разрабами, но его не развиваю), но взять под своё крыло мешает лицензия. Конечно, далеко не факт, что это будет (отчего у ТС и пригорело), но хотя бы не запрещено.
Классический пример — Punto Switcher под крылом Яндекса.
Последнее обновление — 07.02.2019.
А зачем ему обновляться? Я даже не последнюю версию использую и обновляться не собираюсь, потому как в новых версиях только какого-то рекламного барахла добавили.
Версия 4.4.2 от 13.03.2018
сборка 334
Работает, как часы
- Punto Switcher до сих пор не умеет переводить в правильную раскладку такие общепринятые слова как UEFI, .pst, FPS, LED, UI, firmware и еще нескольких дюжин.
- Нет возможности экспортировать список этих слов для оперативного импорта после переустановки программы или на другом ПК.
- Нет даже элементарной сортировки списка этих слов, чтобы исключить повторное внесение тех же элементов списка.
- Некоторые из этих слов не обрабатываются вообще, другие обрабатываются не во всех приложениях.
- Автозамена не всегда срабатывает в Word.
- После многодневного использования режима hibernate Punto Switcher начинает работать вообще непонятно как.
В любом случае, проект не обновляющийся больше года, — мертвый проект. И место таким проектам, на мой взгляд, на открытых площадках типа GitHub.
Наверняка найдутся желающие поддерживать, в целом, хорошую программу.
Если Яндекс поступит так со своим Punto Switcher, то компания, думаю, ничего не потеряет. Наоборот, многие скажут «спасибо!», и уважение аудитории к компании от такого подарка только повысится.
BarakAdama, просьба передать это ответственным за принятие решения лицам.
Первая проблема, описанная в вашем письме, поправлена 5 лет назад https://github.com/samba-team/samba/commit/caff67082a22b4b5250eb73b09e57bb9ab99c346
То есть 1000 глаз всё таки видят и даже правят баги, и опенсорс не так плох как вы описываете. Скорее дело в том, что ребята редко заглядывают в багзиллу.
UPD а, так этот коммит и правит баг из багзиллы. Но другой баг, внесенный не вами. Выходит, что у ребят бардак в трекере, и ваш репорт просто-напросто потерялся.
@Andrey2008 Не вы ли тут уже сотню раз объясняли, что в memset опасно передавать sizeof only, потому что оно считает размер первого элемента массива, а не всего массива. Попахивает, что разработчики по старой памяти из более высокоуровневых языков так пишут, а оно работает здесь немного с нюансом.
Теперь я прекрасно понимаю, откуда у начальника на моей первой работе была привычка определять предкомпиляцией размеры массивов и буферов (defined buffer size). Полезная практика, когда нужно передать не количество элементов, а размер в байтах. Оно и понятно, всё таки он игры делал под Windows 95/98 и после на заре 2000-х.
Вызовы этих memset компилятор удалит, и приватные данные будут продолжать находиться в памяти
Видел гдето интересное обсуждение, а есть ли вообще смысл в "безопасной" очистке данных? Тоесть получается, что данные все равно какуюто часть времени пробыли открытыми, какая разница, удалят их потом или нет? Это с человеческой точки зрения есть разница между секундой и минутой (да и то не всегда), а с точки зрения компьютора в чем разница? Мне кажется, атаку можно придумать и на первый случай, когда ничего не очищается (снять в какойто момент времени дамп памяти и неспеша его просмотреть), так и на второй (снимать дампы памяти по чуть-чуть и смотреть на те данные, которые живут недолго). Или вообще поставить breakpoint на безопасный memset, и все пароли будут как на ладони :)
Не специалист, но сделаю предположение. Ваш процесс рано или поздно завершится, и его место в оперативной памяти сможет занять кто-то другой, и он сможет читать данные, оставшиеся "по наследству". От этого, думаю, и защищаются.
Ну нет, "по наследству" между процессами ничего не передаётся, ОС не позволяет.
Спасибо! Люди на форумах и в блогах действительно говорят, что и в Linux, и в Windows страницы памяти зануляются перед передачей другому процессу. Но я не смог найти никаких "официальных" подтверждений этому (скажем, статей на kernel.org или MSDN). Подскажите, пожалуйста, где можно найти системное изложение темы? Хочется иметь какое-то подобие документации, с которой можно сверяться и на которую можно ссылаться.
Это настолько общепринятое поведение, что я не уверен что оно его вовсе надо указывать. Но можно увидеть подтверждение, например, вот тут: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc
Совершенно верно. Когда компьютер были однозадачными, а данные ходили по Интернету незашифрованными, память никто не чистил. Были, в частности, функции malloc (memory allocate, "дайте мне памяти, какая бы ни была") и calloc (clear and allocate, "дайте мне памяти, заполненной нулями"), и вот в первом случае Вы и получали блок, заполненный тем, что в него клала предыдущая пользовавшаяся им программа. Это было время непуганых идиотов юзеров. А потом — червь Морриса, эксплоиты с переполнением стека, и всё заверте...
Рискуя быть заминусованным, выскажу предположение, что с развитием абстракций (языков без прямого доступа к памяти, в т.ч. интерпретируемых, скриптовых), данное действие становится всё сложнее до невозможности.
Т.е., утрируя, если хочешь написать червь - пиши его на ассемблере! Что очень сокращает число специалистов (а вместе с ним и риск), чтобы заботиться об этом в каждой софтине.
И это уж не говоря о требуемом изначальном уровне доступа. Я вспоминаю истерию по поводу Meltdown\Spectre, а реально много ли было бед из-за них? Возможно, я мало читаю, но не слышал.
Отчего делаю вывод: пусть лучше мой софт будет уязвим для хакеров выше скрипткидди, но я сделаю его лучше (например, быстрее), чем я параноидально обмажусь всеми проверками, которые мне, возможно, ещё и свинью подложат.
данное действие становится всё сложнее до невозможности.
Есть люди, которым это под силу. А значит, опастность существует и игнорироваться не должна.
По поводу Meltdown\Spectre, часто очень сложно определить каким способом утекла некая информация (например, приватный ключ), если она не передавалась в открытом виде. Поэтому, тут тоже достаточно самой возможности, что бы начинать беспокоиться. Тем более, что рабочие экплоиты были продемонстрированы - это не какая то мифическая возможность.
Абсолютно любой замок можно вскрыть или сломать. А раз так, то зачем они вообще нужны? Вы готовы никогда не закрывать дверь своей квартиры?
Кстати, практика подсказывает, что да, можно. Однако, никогда не знаешь, будет ли одномиллиардный шанс именно твой, когда кто-то зайдет в твой подъезд, зайдёт на твой этаж, дёрнет твою ручку и твоя квартира откроется, являя вкусную плазму, топовый ноут и $1000 прямо на тумбочке для жены, а то ещё и саму жену на "закуску"
Так что всё же лучше закрывать. Хоть на 1 замок, не на 10, но чтоб войти было сложнее, чем просто нажать на ручку...
Как подсказывает практика, то зайдет к вам не случайный человек с улицы, а сосед-алкоголик.
А количество замков уже зависит от того, что вы прячете за дверью, и как много человек об этом знает.
Так что всё же лучше закрывать. Хоть на 1 замок, не на 10, но чтоб войти было сложнее, чем просто нажать на ручку...
"Мне не надо бежать быстрее медведя, мне надо бежать быстрее тебя" (c)
Для этого: Перезаписывать память – зачем?
@Andrey2008, при всем уважении к Вам и вашей компании, все же считаю необходимым напомнить тезис о том, что Хабр - не жалобная книга. Тем более, в ситуации с открытым ПО. Со стороны выглядит просто великолепно. Это вы 9 лет знаете о существовании ошибки, знаете пути их исправления, и... Кроме как жаловаться ничего не делаете.
А по сути, @Lure_of_Chaos чуть выше вполне разумно высказался. Мне особо добавить нечего. Разве что посокрушаться. Давно собираюсь написать статью об эволиционном развитии программного кода и о том, что эволючионно почти всегда выживает тот, кто обеспечивает массовость, пусть и ценой короткой жизни. Отличное было выступление Михаила Никитина на "УПМ-7". Так и подбивает повторить, но применительно к коду. Даже ченовик давно лежит. Только вот меня постоянно упрекают в том, что демагог. И мои аналогии ничего не доказывают. Потому и двигается данная статья очень и очень медленно.
По сути мы на одной стороне. Что PVS-Studio, что Rust, что MISRA и прочие стандарты... Все они про надежность и безопасность. Но увы. О безопасности и надежности вспоминают ровно в тот момент, когда под угрозой оказывается массовость воспроизводства и скорость вывода итогового на рынок. Или (опять же строго эволюционно) или в очень нишевых областях. Тех областях, которые не интрересны массовому рынку по причине очень малого питания. Мне повезло (???) работать в одной из таких областей. Но я прекрастно понимаю почему в других местах совершенно противоположный подход к качеству кода. Не важно открытого или закрытого.
Подводя итог скажу лишь одно. Вы делаете очень важную работу публикуя типичные ошибки. Отдельно спасибо за оформленные баг-репорты к открытым проектам. Но точно не стоит писать статьи типа этой. Тут полный спектр всякого. От личной обиды (мы нашли и сказали, а нас игнорят) до ошибки выжившего (вы же проверяете и закрытый код и в курсе того, как там дела обстоят). А жизнь... Жизнь она всегда несправедлива...
Эээ... это какое-то Ваше восприятие статьи :). Это не жалоба. Это фиксация примера, что открытость проекта сама по себе почти ничего не значит и борьба с вредным мифом. Личная обида? Вообще мимо. Я ржал, когда я понял, что за уведомление я получил :). Но раз испытал лёгкий шок, решил его зафиксировать в виде заметки.
Что делать. Не все одинаково прочитанное воспринимают.
На самом деле ваш цикл статей очень хорош. Сколько потенциальных ошибок copy-paste было не допущено ровно потому что вы всегда с них начинаете! Я даже посчитать не возьмусь. А ведь именно разработчику их просто не видно. Мозг сам себя обманывает выдавая желаемое за действительное. И инструмент безусловно хорош.
Что до мифа.... Ну не знаю. Каждый серьезный RCE в ядре Linux ставит под угрозу Android. Хотя, казалось бы Google, разработчики на зарплате в хорошем количестве и с хорошей зарплатой. Да не один год по времени уже. Можно было или вычистить или переписать. Я бы не взялся ни опровергать этот миф, ни вступаться за него. Открытый код уже неоднократно доказал свое право на существование. Как и закрытый. Не мне судить кто из них более качественный. Мое дело свой код качественно писать. И даже шире - свои изделия качественно проектировать. Ибо код - это только винтик в огромном механизме изделия, а чаще даже комплекса изделий.
Потому ничего личного. С нетерпением жду следующую статью.
Ух, повеяло нулевыми! FUD. Высосаные из одного места статьи. Developers, Developers, Developers! Ну вот не надо про качество закрытого кода. При прочих равных открытый код лучше, спорить с этим сложно.
1000 глаз, которые не хотят проверять код открытых проектов