Аргумент "раз ты не исследовал каждую микросхему - то смысла в защите нет" - это чистой воды подмена понятий. В жизни и в безопасности абсолютного не бывает: уязвимости всегда есть. Но мы всё равно пристёгиваем ремень, ставим замки и шифруем трафик.
Следуя вашей логике: раз завод нельзя защитить от диверсии на 100% - то не нужно ставить камеры и замки.
И да, цензура и политические статьи не ищут шпионов, они ищут повод. Репост, мем, неосторожная фраза - и ты уже под ударом. Приватность нужна каждому: не потому что ты преступник, а потому что любая информация в чужих руках превращается в инструмент давления.
Со временем у разработчика появляется свой «словарь» для нейминга. Постоянное чтение чужого кода помогает понять, какие названия работают, а какие только запутывают.
Вот, например, переменная count. Опытный программист почти всегда назовёт её именно счётчиком. А у джунов встречаются самые разные варианты - total, inc, иногда даже что-то вроде counnnt.
Есть ещё и влияние самого языка. В Go нейминг обычно максимально короткий и лаконичный:
Помню, когда интернет был по-настоящему свободным и только принимали закон о СОРМ, люди тоже говорили: «Что вам скрывать? Это для вашей же безопасности». В итоге безопасности не прибавилось: но появился «пакет Яровой» с кольцевым месячным буфером всего трафика, запретами на публикации, на чтение. Но и этого товарищу майору оказалось мало — он уже лезет в телефон. А особо одарённые индивиды всё ещё продолжают вещать о том, что нам нечего скрывать.
Ждём следующую статью "Как с помощью brace expansion создать больше одной папки в Linux", "Повышаем свою эффективность в Linux: history expansion и секреты быстрых команд", "Секреты быстрого перехода в домашнюю директорию", "Эффективное чтение логов с помощью less и tail"
Я не шарпист, пишу на жабе, но в жабе ты бросаешь эксепшен в любом слое, он по стеку возвращается на самый верхний слой (чаще всего это какие нибудь контроллеры), а там обрабатываешь его и возвращаешь http error с нужным кодом и описанием из эксепшена и я не представляю какой геморрой пробросить это все с помощью того же return, который фактически предназначен для возврата результата, а не ошибки. Создаётся такое впечатление, что автор в разработке недавно.
Я не безопасник, но Docker-контейнер по умолчанию запускается с root-правами внутри, и если не сброшены лишние привилегии или не настроена изоляция (через seccomp, AppArmor, user namespaces и т.д.), то уязвимое приложение внутри может получить доступ к ядру хоста или через volume внести изменения (например, подложить скрипт, изменить файлы и т.п.).
Фактически, запуск потенциально опасного кода в контейнере опаснее, чем запуск того же кода от непривилегированного пользователя на хостовой системе, если не отключены лишние capabilities или, что хуже, используется --privileged.
Если нужно безопасно запускать контейнеры, стоит использовать:
USER в Dockerfile,
сбрасывать все привилегии (--cap-drop=ALL),
включить --security-opt no-new-privileges,
не монтировать чувствительные ресурсы вроде docker.sock,
Здоровья, сил и терпения. Потеря физических возможностей и осознание своей беспомощности психологический тяжёлый момент. У меня был сложный перелом голеностопа пол года на вытяжке/в гипсе и было до слез обидно, что я не могу элементарных вещей без посторонней помощи. Обидней всего было прийти в поликлинику и понять что я не могу туда попасть из-за огромных ступенек и мраморного скользкого пандуса под углом 45°.
Идеальный подход или вызов для инженеров был после великой отечественной войны в период Сталина: снижение себестоимости продукции за счёт увеличения производительности труда.
Да все мы помним времена шарашкин контор, когда инженеров судили, а потом они под присмотром НКВД работали за паек.
Если коротко, то он говорит, что если бы разработчики ПО сконцентрировались на оптимизации работы ПО, то старая техника работала бы так же быстро, как современная. А это вполне себе хорошая инженерная задача. Но цена такой оптимизации - сокращение частоты выпуска новых функций и продуктов.
На чем сконцентрироваться выбирает не разработчик, а бизнес. Простая математика: есть стоимость человеко-часа, можно эти деньги потратить на оптимизацию ПО, либо на новую фичу.
Шкафы приезжают ко мне в дом и вместе с ними 3 сборщика, которые тратят 3 полных рабочих дня на её сборку и монтаж. При этом сборщики привозят с собой большое количества инструментов, типа лобзиков, шуруповертов, перфораторов, дисковых пил и др.
Дело не в не совершенном ПО, а в не совершенном мире. Вы конечно можете внести в программу миллион параметров, но где гарантия, что все эти параметры получены верно. Простой пример: ни в одном помещении нет идеального 90° угла, есть коммуникации расположение которых в пространстве измерить сложно (например: газовая труба, расстояние от пола, расстояние от стены - все это не константы, труба может быть криво сварена или криво установлена), типы стен и поверхностей.
Вот и получается что приходит мебель, а потом ее по месту уже начинают подгонять.
Классика) Кто-то опять решил, что принципы проектирования мешают творить великий монолит на 30 тысяч строк в одном классе.
SRP мешает писать God-классы, где всё: от бизнес-логики до отправки email и рисования графиков.
OCP бесит, потому что расширять — сложно, а переписать всё к чёрту — приятно и быстро (до следующей итерации боли).
LSP — слишком академично, ведь кто в проде проверяет, что Square — не Rectangle? Ну, кроме баг-трекера, конечно.
ISP раздражает, ведь лучше засунуть makeCoffee() в общий интерфейс IWorker, чем подумать, кто реально это должен делать.
DIP вообще анекдот: зачем абстракции, когда можно new MyService() и страдать от tightly coupled ада?
Не нравится SOLID? Не вопрос. Но тогда не удивляйтесь, что рефакторинг вашего кода вызывает PTSD у команды, а тесты пишутся через боль и жертвоприношения)
SOLID, DRY, KISS, YAGNI — всё это давно сформулировано, обосновано и проверено практикой. Но с завидным постоянством появляются новые "революционные принципы", в которых узнаются старые идеи, только под другим соусом. Такое ощущение, что у новичков наступает стадия «изобретения философского велосипеда».
Осталось дождаться, когда кто-то на Хабре представит миру "новаторские архитектурные концепты", а по сути — очередную реинкарнацию паттернов из книги "Банды четырёх". Назовёт их S.T.A.G. или D.O.N.K.E.Y. и объяснит, почему это next big thing.
Конечно, путь проб и ошибок — важная часть роста, но знание классики позволяет экономить годы. И время на псевдооткрытия тоже.
>go в DevOps не используется
А на каком языке вы пишите расширения k8s?
Аргумент "раз ты не исследовал каждую микросхему - то смысла в защите нет" - это чистой воды подмена понятий. В жизни и в безопасности абсолютного не бывает: уязвимости всегда есть. Но мы всё равно пристёгиваем ремень, ставим замки и шифруем трафик.
Следуя вашей логике: раз завод нельзя защитить от диверсии на 100% - то не нужно ставить камеры и замки.
И да, цензура и политические статьи не ищут шпионов, они ищут повод. Репост, мем, неосторожная фраза - и ты уже под ударом. Приватность нужна каждому: не потому что ты преступник, а потому что любая информация в чужих руках превращается в инструмент давления.
Пока "говноделы" заняты делом, мы можем спать спокойно
Со временем у разработчика появляется свой «словарь» для нейминга. Постоянное чтение чужого кода помогает понять, какие названия работают, а какие только запутывают.
Вот, например, переменная count. Опытный программист почти всегда назовёт её именно счётчиком. А у джунов встречаются самые разные варианты - total, inc, иногда даже что-то вроде counnnt.
Есть ещё и влияние самого языка. В Go нейминг обычно максимально короткий и лаконичный:
repo.Get(42)
repo.List(10, 0)
repo.Save(&u)repo.Delete(42)
А в Java, особенно в Spring - наоборот, длинный и самодокументируемый:
userRepository.findUserEntityById(42L);userRepository.findAllUserEntitiesWithPagination(10, 0);
userRepository.saveUserEntity(userEntity);
userRepository.deleteUserEntityById(42L);
В Go читаемость держится за счёт контекста, а в Java - за счёт длинных «говорящих» имён. Оба подхода рабочие, но философия разная.
>Завести второй акк и переписываться с самим собой в комментариях
А ты хорош)
Рейтинг статьи говорит сам за себя.
Помню, когда интернет был по-настоящему свободным и только принимали закон о СОРМ, люди тоже говорили: «Что вам скрывать? Это для вашей же безопасности». В итоге безопасности не прибавилось: но появился «пакет Яровой» с кольцевым месячным буфером всего трафика, запретами на публикации, на чтение. Но и этого товарищу майору оказалось мало — он уже лезет в телефон. А особо одарённые индивиды всё ещё продолжают вещать о том, что нам нечего скрывать.
Ждём следующую статью "Как с помощью brace expansion создать больше одной папки в Linux", "Повышаем свою эффективность в Linux: history expansion и секреты быстрых команд", "Секреты быстрого перехода в домашнюю директорию", "Эффективное чтение логов с помощью less и tail"
>Мой коллега сейчас проверяет гипотезу: обучает junior-специалистов работе с ИИ с нуля.
Интересно откуда у джунов возьмётся понимание кода если его пишет ИИ?
>Согласно Veracode, 45% AI‑сгенерированного кода содержат уязвимости, особенно XSS и log injection.
Видимо он написан junior-dev-senior-promt инженером
Проблема курицы и яйца
Я не шарпист, пишу на жабе, но в жабе ты бросаешь эксепшен в любом слое, он по стеку возвращается на самый верхний слой (чаще всего это какие нибудь контроллеры), а там обрабатываешь его и возвращаешь http error с нужным кодом и описанием из эксепшена и я не представляю какой геморрой пробросить это все с помощью того же return, который фактически предназначен для возврата результата, а не ошибки. Создаётся такое впечатление, что автор в разработке недавно.
Про 3 пункт не понял.
Я не безопасник, но Docker-контейнер по умолчанию запускается с root-правами внутри, и если не сброшены лишние привилегии или не настроена изоляция (через seccomp, AppArmor, user namespaces и т.д.), то уязвимое приложение внутри может получить доступ к ядру хоста или через volume внести изменения (например, подложить скрипт, изменить файлы и т.п.).
Фактически, запуск потенциально опасного кода в контейнере опаснее, чем запуск того же кода от непривилегированного пользователя на хостовой системе, если не отключены лишние capabilities или, что хуже, используется --privileged.
Если нужно безопасно запускать контейнеры, стоит использовать:
USER в Dockerfile,
сбрасывать все привилегии (--cap-drop=ALL),
включить --security-opt no-new-privileges,
не монтировать чувствительные ресурсы вроде docker.sock,
и по возможности - запускать rootless Docker.
Что делать вайбкодеру? — учить язык
problem solving
Хай гайз, ай хэв некоторый проблем, ай поставил митинг на 15.00 где мы будем проблем солвинг. Участие ол обязательно.
Здоровья, сил и терпения. Потеря физических возможностей и осознание своей беспомощности психологический тяжёлый момент. У меня был сложный перелом голеностопа пол года на вытяжке/в гипсе и было до слез обидно, что я не могу элементарных вещей без посторонней помощи. Обидней всего было прийти в поликлинику и понять что я не могу туда попасть из-за огромных ступенек и мраморного скользкого пандуса под углом 45°.
Сейчас бы писать код в AST дереве согласно лучшим практикам SOSAL, а не это всё
Да все мы помним времена шарашкин контор, когда инженеров судили, а потом они под присмотром НКВД работали за паек.
На чем сконцентрироваться выбирает не разработчик, а бизнес. Простая математика: есть стоимость человеко-часа, можно эти деньги потратить на оптимизацию ПО, либо на новую фичу.
Дело не в не совершенном ПО, а в не совершенном мире. Вы конечно можете внести в программу миллион параметров, но где гарантия, что все эти параметры получены верно. Простой пример: ни в одном помещении нет идеального 90° угла, есть коммуникации расположение которых в пространстве измерить сложно (например: газовая труба, расстояние от пола, расстояние от стены - все это не константы, труба может быть криво сварена или криво установлена), типы стен и поверхностей.
Вот и получается что приходит мебель, а потом ее по месту уже начинают подгонять.
Классика) Кто-то опять решил, что принципы проектирования мешают творить великий монолит на 30 тысяч строк в одном классе.
SRP мешает писать God-классы, где всё: от бизнес-логики до отправки email и рисования графиков.
OCP бесит, потому что расширять — сложно, а переписать всё к чёрту — приятно и быстро (до следующей итерации боли).
LSP — слишком академично, ведь кто в проде проверяет, что Square — не Rectangle? Ну, кроме баг-трекера, конечно.
ISP раздражает, ведь лучше засунуть makeCoffee() в общий интерфейс IWorker, чем подумать, кто реально это должен делать.
DIP вообще анекдот: зачем абстракции, когда можно new MyService() и страдать от tightly coupled ада?
Не нравится SOLID? Не вопрос. Но тогда не удивляйтесь, что рефакторинг вашего кода вызывает PTSD у команды, а тесты пишутся через боль и жертвоприношения)
SOLID, DRY, KISS, YAGNI — всё это давно сформулировано, обосновано и проверено практикой. Но с завидным постоянством появляются новые "революционные принципы", в которых узнаются старые идеи, только под другим соусом. Такое ощущение, что у новичков наступает стадия «изобретения философского велосипеда».
Осталось дождаться, когда кто-то на Хабре представит миру "новаторские архитектурные концепты", а по сути — очередную реинкарнацию паттернов из книги "Банды четырёх". Назовёт их S.T.A.G. или D.O.N.K.E.Y. и объяснит, почему это next big thing.
Конечно, путь проб и ошибок — важная часть роста, но знание классики позволяет экономить годы. И время на псевдооткрытия тоже.
Бабушка в окошках разбирается и драйвер может обновить и реестр поправить, а с линуксом беда - там демоны