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

В последнее время замечаю огромное количество информации по поводу замедления Великого, но очень мало где видел конкретику о том, как именно это работает. Одно лишь отчаяние "мы все умрём".

Сразу скажу, что буду говорить обо всём, что известно на данный момент. Понятно, что с этим разбирался далеко не один я: огромное спасибо обывателям ntc party форума за проделанный ресёрч.

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

UPD 10.08.2024 Многие жалуются на недоступность ютуба в целом: не грузит домашнюю страницу. Переживать не стоит, оно обрабатывается всё тем же ТСПУ по всё той же стратегии, обходы должны работать.

В этой статье представлен большой тренинг Рика Хартли по разводке земли в печатных платах. Перевёл и озвучил данное видео Dmitry Muravyev, за что ему огромное спасибо. Я всего лишь сделала конспект этого замечательного тренинга, чтоб люди могли ознакомиться с ним быстрее, чем смотреть двухчасовое видео, либо вернуться к каким-то отдельным темам, если позабылось. Категорически рекомендую ознакомиться с источником.

Впервые люди начали использовать землю в качестве проводника около 300 лет назад для отведения молний от зданий. Молния сама естественным образом стремится разрядиться на землю. Так что установив железный стержень на крыше здания и проведя от него  большой толстый провод вниз по зданию к балке, вбитой в землю, люди отводили молнии от зданий. Это был первый опыт использования земли в качестве возвратного пути для протекания тока. Из чего скоро стало ясно, что землю можно использовать в качестве возвратного пути и для других целей.

Немного занимательной статистики с боди-позитивными пакетами-рекордсменами в официальных репозиториях Arch Linux.

Nginx, универсальный веб-сервер, имеет ключевое значение для многочисленных интернет-инфраструктур, занимает доминирующую долю рынка с момента своего создания в 2004 году, получил широкое распространение на веб-сайтах и в контейнерах Docker. В этой статье рассматриваются тонкости Nginx, основное внимание уделяется директивам location и alias, которые играют центральную роль в том, как Nginx обрабатывает определенные URL-адреса. Мы также изучим потенциальные уязвимости, возникающие из-за неправильных конфигураций, и продемонстрируем, как они могут привести к эксплойтам безопасности, опираясь на исследования, представленные Orange Tsai на конференции BlackHat 2018.

Руководство дополнительно проиллюстрирует эти моменты посредством тщательного изучения популярных репозиториев с открытым исходным кодом, с использованием GitHub Code Search для выявления потенциальных уязвимостей конфигурации Nginx. Реальные тематические исследования с участием Bitwarden и Google HPC Toolkit подчеркнули значительный риск раскрытия данных, если эти уязвимости не будут устранены. Кроме того, мы представим NavGix, автоматизированный инструмент, предназначенный для обнаружения этих уязвимостей методом «черного ящика», предоставляющий исчерпывающую информацию о сложностях, уязвимостях и возможных неправильных конфигурациях Nginx.

Для решения задач автоматизации рутинных процессов для системных администраторов и DevOps чаще всего используются или bash-сценарии или python. Первое решение косвенно используется и в описании Dockerfile, поскольку сценарий исполняемых команд принципиально ничем не отличается от запуска скрипта в какой-либо shell, второй подход чаще ассоциируется с автоматизацией, связанных с взаимодействием с хранилищами данных. Но несправедливо было бы обойти стороной возможность создания исполняемых сценариев на языке Kotlin, которые могут стать полноценной заменой bash-сценариям.

В этой статье мы рассмотрим несколько примеров использования Kotlin Scripting (KTS) для автоматизации в распределенной системе, будем использовать долгоживущие скрипты с ожиданием заданий через RabbitMQ, а также поработаем с файловой системой, внешними сервисами, а также попробуем использовать KTS для сборки Docker-контейнеров.

Идея данного текста возникла из многочисленных расспросов друзей и коллег, кто решился на какую-либо релокацию в столь нелегкое время.

Дело в том, что в августе этого года я улетел за 12000 км от родного дома в страну, оказаться в которой жизнь меня не сильно готовила. Ехал к девушке, которая приняла оффер зарубежной компании и уехала несколько раньше. Мне удалось убедить работодателя, что труд на удаленке будет достаточно эффективен, хотя должность админа с входящей в круг обязанностей задачей следить за активным оборудованием и железными серверами в компании, слабо представлялась работодателю в данном режиме. Тем не менее, данный материал я готовлю из Сан Паоло, и вместо написания каких-то инструкций или описания интересных рабочих проектов, хотел бы коснуться темы подготовки персональной инфраструктуры, которая может пригодиться при подобном переезде на неопределенный срок. Стоит отметить, что я не любитель тотальной автоматизации всего и вся в своей жизни и "умный дом" из заголовка для привлечения внимания у меня до сих пор лишь в планах на "пенсионные" годы. К тому же это мой первый выезд за рубеж, глаз не еще "не замылен", потому такой опыт возможно, будет интересен и полезен читателям.

Оговорюсь также, что выбор оборудования для реализации тех или иных задач не является какой либо рекламой, а приведен лишь для примера с объяснением критериев выбора. В моем случае это оборудование, с которым либо был опыт работы, либо которое я смог себе позволить купить, не прибегая к ограблению банка, либо то, что имелось на руках и могло быть применено по назначению. Подробные технические моменты также оставим за кадром, это не задача данного обзорного материала, но некоторые нюансы для меня были не очевидны, я постараюсь их описать.

Я знаю многое о велосипедах в Enterprise-разработке. Видел издали, катался на них, собирал сам, но наступают моменты, когда типичные задачи пора перевести на типичные решения. В статье расскажу о 4 self-hosted сервисах, которые освобождают уйму времени на действительно важные вещи.

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

В Интернетах много разных очень крутых сервисов, которые позволяют сделать свой почтовый сервис с собственными адресами. Однако, захотелось приключений и появилась тяга к созданию чего-нибудь своего. Зачем что-то делать просто, если можно причудливо?

Предпосылки, что и зачем описал тут: статья

Небольшой ретроспективный опус о радио, о том, что всё развивается по спирали и о том, как китайские инженеры сделали радиосвязь доступнее для миллионов людей.

Не раз наша команда сталкивались с задачей, связанной с хранением и использованием IP-адресов в базе данных. Предположим, что есть типичная задача: необходимо парсить огромное количество диапазонов адресов (~300k) с известного ресурса, а далее определять страну по IP-адресу клиента. Кажется, ничего особенного. Это довольно просто решается любым ниже описанным способом при малых нагрузках. Но если у нас тысячи пользователей или наш сервис является прокси перед всеми остальными? В этом случае не хочется быть бутылочным горлышком и приходится бороться за каждую долю секунды.

Компьютер — это просто. Или нет?

Введение

1. Повреждения головок при аварийном завершении работы диска (залипание на поверхности, неправильный заход на парковку и т.п.).
2. Повреждения головок при физическом воздействии на диск (падение диска, удар по диску, сильные вибрации во время работы и т.п.).
3. Повреждения головок при электрическом шоке (сгорел блок питания, скачок напряжения в сети электропитания, переполюсовка при подключении питания (не спрашивайте меня как, разъем каким-то образом умудряются другой стороной забить) на накопитель и т.д.).
4. Заводской брак.
5. Естественный износ.