Любой начинающий DevOps начинает своё знакомство с Git. Этот инструмент стал неотъемлемой частью рабочего процесса разработчиков по всему миру. Во многих курсах и руководствах по DevOps описывается настройка серверов через популярные платформы, такие как GitLab, а иногда и Gitea. Однако мне стало интересно попробовать другой путь — использовать встроенный в Git инструмент GitWeb.

В мире, где информация постоянно обновляется, а найти что-то можно с молниеносной скоростью, встаёт вопрос: а нужны ли вообще книги для программистов? Ведь в интернете есть множество бесплатных обучающих материалов, туториалов, видеоинструкций и чатов на базе генеративного искусственного интеллекта, которые, казалось бы, могут полностью заменить традиционные источники знаний — книги.

Однако, на мой взгляд, книги всё ещё остаются важным и незаменимым инструментом для изучения программирования, особенно для новичков. В этой статье я, Бартенев Евгений, автор и техлид курсов «Python-разработчик» в Яндекс Практикуме, расскажу, почему я так считаю. А также поделюсь своей подборкой книг как для начинающих разработчиков, так и для тех, кто уже пишет код не первый день.

Последние инновации в сфере ИИ, наиболее примечательными из которых стали проекты наподобие GPT-4, очевидно, могут иметь далеко идущие последствия для общества: от утопического избавления от монотонного труда до антиутопического ущерба для работы художников в капиталистическом обществе, а также до экзистенциальных угроз самому человечеству.

Лично я получил формальное образование дата-саентиста, даже выиграв в высококонкурентном конкурсе по машинному обучению в одном из лучших университетов Австралии и написав магистерскую, для которой создал в MATLAB с нуля собственные библиотеки. Я не гений в этой сфере, но, очевидно, лучше большинства конкурентов, то есть практиков вроде меня; я не могу, сидя в пещере, создавать собственные библиотеки на C, но умею читать учебники, реализовывать готовые решения на языках высокого уровня и использовать библиотеки, написанные элитными организациями.

Поэтому с глубочайшим сожалением должен объявить, что следующий человек, который начнёт говорить мне о реализации ИИ, получит от меня сеанс живительных процедур над позвоночником; иными словами, я сломаю ему нафиг шею. Мне очень-очень жаль.

Привет всем! Недавно я решил поэкспериментировать с SonarQube и создать свой собственный кастомный плагин для проверки кода на соответствие моим правилам разработки. В этой статье я поделюсь с вами своим опытом и покажу, как вы тоже можете создать такой плагин своими руками.

Одним из важным инструментом разработчика, в не зависимости от языка (и религиозных убеждений), является система контроля версий (VCS). И практически промышленным стандартом стала такая распределенная система как GIT. В повседневной работе мы (разработчики, DevOps инженеры, технические писатели и все причастные) используем ее чтобы нести людям добро и свет объединять усилия команд в работе над нашими проектами. И все давно уже выучили «на зубок» основные команды (если не выучили то бегом учить, тут есть отличная книжка) и превратили в рутину то что совсем не давно (олды тут?) казалось гениальным, сложным, а кому то магическим. А современные IDE еще больше нам упростили жизнь, спрятав от нас командную строку и git команды, заменив на возможность кликать мышкой. Но постойте, разве вам в детстве не было интересно понять как та или иная игрушка устроена внутри, как работает холодильник или мотор в папиных жигулях (олды все же тут?)? Так вот и мне стало интересно заглянуть под капот GITу. Конечно как и с любым сложным механизмом уровень этого «заглядывания» под капот может быть разным, кому то будет достаточно увидеть крышку мотора и отверстие куда лить незамерзайку, а кому то «заглянуть под капот» это дойти до марки стали используемой для изготовления той или иной детали жигулей. Поэтому давайте сразу обозначим уровень нашего погружения в этой статье. В статье мы рассмотрим в деталях что происходит когда мы делаем привычные нам «git clone/push», посмотрим как этот процесс устроен и какие есть в нем возможности. Сущности и процессы, которые конечно же останутся за рамками этого повествования, можно будет самостоятельно найти (ссылку я указал выше), ибо охватить такую обширную тему как Git, а тем более его подкапотное пространство, не представляется возможным за раз. Так что все кому интересно прошу под кат.

Привет, Хабр! Меня зовут Георгий Меликов, я из VK Cloud и руковожу там инфраструктурной разработкой (IaaS) облака, где мы создаём SDN (Software Defined Networks) — программно определяемые сети; SDS (Software Defined Storages) — программно определяемые хранилища; и другие решения.

А ещё на досуге я — контрибьютор файловой системы OpenZFS с 2016 года.

В этой статье поговорим о наших подходах к разработке на примере создания нашего SDN. Мы ставим перед собой несколько целей:

1) Разрабатывать быстро, чтобы итерации были явно очерченными  и понятными. Хотим, чтобы у нас вырабатывался дофамин от закрытия спринтов, и было понятно, как жить дальше.

2) Эксплуатировать системы без людей — полностью автоматически.

3) Использовать принцип «Дизайн на отказ». Система должна уметь переживать любой возможный сбой и проблему, т.е.обладать так называемым качеством самовосстановления (self-healing).

Предлагаю пройтись эволюционно от простого примера "облака на минималках" до нашей production среды на несколько ЦОДов, собрав по пути проблемы из нашей реальной жизни.

Привет, Хабр! В этой статье Вячеслав Закариев, DevOps из компании Henderson, рассказывает о миграции в облако инфраструктуры крупного российского производителя и селлера одежды. Под катом: переезд с Hyper V на VMware, организация собственного ЦОД в офисе, интеграция его в облако, 140+ виртуальных машин от 250 ГБ до 4 ТБ каждая, честный отзыв Вячеслава по итогам переезда и много чего ещё.

Исследование СайберОК содержит в себе интересные ответы на то, что находится на интересном порту 7547/TCP, о котором многие могут услышать впервые. Пробежимся по тому, какую опасность в себе представляет этот порт и какие интересные физические устройства обитают на нём. Построим поверхность атаки, вспомним как беспощадно наводили шуму эти маленькие коробочки – разложим это всё тщательно на атомы – на TP-Link-и, Keenetic-и, Mikrotik-и, а также проанализируем насколько это всё уязвимо. Лээтс го!

Как говорится, «не будите во мне ботана». Иногда кто-нибудь беспечно задаст мне, казалось бы, невинный вопрос — и я убиваю следующие несколько часов (в описываемом случае — дней), чтобы полноценно сформулировать ответ. Обычно всё это заканчивается с моей стороны очередной филиппикой на mastodon или в каком-нибудь приватном чате. Но на сей раз не буду этим ограничиваться и напишу целый пост.

Вот с какого невинного вопроса всё началось:

А почему UID начинаются с 0, но PID начинаются с 1?

Если совсем коротко: в Unix PID (идентификаторы процессов) начинаются именно с 0! PID 0 просто не отображаются в пользовательском пространстве через традиционные API.  PID 0 запускает ядро, а затем практически уходит на покой, только немного участвует в работе планировщика процессов и в управлении питанием. Кроме того, на просторах Интернета доминирует заблуждение о PID 0, всё из-за одного ошибочного утверждения в Википедии, которому уже 16 лет.

В заключении к посту я дам несколько расширенную версию этого короткого ответа, но если хотите до него дойти вместе со мной — давайте разберём достаточно длинную среднюю часть.

Но, конечно же, любой желающий может просто загуглить, что такое PID 0, верно? Зачем мне вообще всё это писать?

Привет, Хабр. Меня зовут Владимир Утратенко, я — Head of Infrastructure and Security в Uzum Market. У меня богатый опыт найма DevOps-инженеров, ведь последние 6 лет я — нанимающий менеджер. А ещё много лет подряд занимаюсь DevOps как моделью разработки. Сегодня мы поговорим про боли в CI/CD, которые часто упускают из вида DevOps-специалисты, лиды и CTO.

Всем привет. Меня зовут Максим, и уже почти два года я содержу домашний сервер.

На данный момент использую его не только я. Многие сервисы находятся в публичном доступе, также я предоставляю виртуальные машины и много других чувствительных сервисов своим знакомым: дисковое хранилище, базы данных и тд. В связи с чем серьезно встает вопрос безопасности. В этой статье я расскажу про то, как я стараюсь обеспечивать безопасность в своей домашней сети.

Записки «чайника», травмированного тензорным исчислением

Тема, заявленная в названии, пожалуй, самая запутанная в тензорном исчислении. Высокоучёные авторы мудрых книг в большинстве случаев ограничиваются только формальными определениями понятий ко- и контравариантности, не опускаясь до подробного пояснения их геометрической и физической сути. Похоже, в этом вопросе они сознательно или бессознательно воспроизводят ситуацию, характерную для квантовой физики: «Не старайтесь понять, просто считайте!». Но если в квантовой физике подобный подход безальтернативен, то в данном случае – вряд ли.

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

Математика остаётся непонятной для многих потому, что нам её объясняют люди, которые понимают её на интуитивном уровне, или, выражаясь более изящно, «на уровне интуитивных образов» [1-7 ≡ Л.1, с. 7]. Нам же, нематематикам, для того, чтобы что-то понять, надо это «что-то» увидеть не в абстрактном («интуитивном»), а в реальном, физически представимом пространстве (по-научному это – «визуализация») или, ещё лучше, поковырять его пальцем (научный термин пока еще не придумали. Открыт приём предложений).

Привет, Хабр!

Мы, сервисные инженеры, сталкиваемся с GRUB2 ежедневно. А вот когда стало любопытно посмотреть на загрузчик комплексно, то в интернете и в учебнике Linux нашли лишь несколько команд: как заново проинсталлировать загрузчик и обновить текущую конфигурацию. «А почему так мало?», — была наша первая мысль.  Решили восполнить пробел — так появилась эта статья. А для иллюстрации попросили нейросетку изобразить, «как выглядят эпичные проблемы с GRUB» -- вот что вышло.

Доступ к файлам через отображение-в-память (mmap) — это способность некоторых операционных систем отобразить содержимое какого-либо файла в адресное пространство программы. Сама программа получает доступ к содержимому файла через указатели, как если бы сам файл был бы целиком загружен в оперативную память. Операционная система прозрачно загружает части файла в оперативную память, и автоматически выгружает их, когда памяти не хватает.

MMAP захватила умы программистов СУБД на многие десятилетия, как альтернатива буферу данных. И вот здесь следует отметить, что в mmap имеются серьёзные проблемы с корректностью и скоростью работы с данными в современных СУБД. В реальности, некоторые известные СУБД сперва использовали mmap для работы с "больше-чем-вмещается-в-память" базами данных, но вскоре обнаружили эти скрытые ограничения, которые принудили их к самостоятельному управлению файловым вводом/выводом, после заметных трат на инженерные исследования. В этом смысле mmap и СУБД подобны сочетанию кофе и острой пищи: неудачное сочетание, которое не очевидно, пока сам не попробуешь.

Покуда разработчики по прежнему пытаются использовать mmap в новых СУБД, мы написали эту статью, чтобы предупредить остальных, что mmap это не подходящая замена привычному буферу. Далее мы обсудим основные недостатки mmap, а также покажем явные ограничения производительности, которые мы обнаружили в наших экспериментах. На основании этих находок мы поделимся рецептами, когда разработчикам СУБД следует избегать mmap для реализации файлового ввода/вывода.

Для ЛЛ: RAID-5 совершенно не подходит для современных массивов из дисков на 5-10 Тб по нескольким причинам.

Привет, Хабр! Недавно я выступал на Moscow Python Conf, где делился нашим опытом создания и использования CI/CD пайплайнов. В данной статье я расскажу об этих пайплайнах, раскрою их особенности и покажу, как они помогают нам быстро доставлять код и поддерживать высокий показатель Time To Market. Надеюсь, что наш опыт будет полезен и вам.