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

Когда CloudFlare только появился, это была настоящая революция в веб-хостинге: в два клика, без переезда на другой сервер, к своему сайту можно было подключить профессиональный CDN, который экономил кучу трафика, ускорял загрузку статических файлов и еще защищал от DDoS. Раньше позволить себе такое могли только компании за большие деньги, а теперь это стало доступно каждому, еще и бесплатно!

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

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

Следить за «интимной жизнью» программ на Linux помогает утилита strace, которой и посвящена эта статья. К примерам использования «шпионского» оборудования прилагаются краткая история strace и описание устройства подобных программ.

werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. Как и обещали, выход версии v1.0 знаменовал начало добавления в werf новых возможностей и пересмотра привычных подходов. Теперь мы рады представить релиз v1.1, который является большим шагом в развитии и заделом на будущее сборщика werf. Версия доступна на данный момент в канале 1.1 ea.

Основа релиза — это новая архитектура хранилища стадий и оптимизация работы обоих сборщиков (для Stapel и Dockerfile). Новая архитектура хранилища открывает возможности к реализации распределенных сборок с нескольких хостов и параллельных сборок на одном хосте.

16 марта московский офис FunCorp перешёл на удалённый режим работы. Как решились на этот шаг, какие риски закрыли и с какими сложностями столкнулись в первую неделю — делимся своим опытом в этой статье.

С чего всё началось

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

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

В начале прошлого года мы сравнили зарплаты удалённых и офисных сотрудников за 2017-2018 гг. и выяснили, что удалённые сотрудники в регионах в среднем зарабатывают на 40% больше офисных. Сейчас, когда накопилось достаточно данных, мы решили сравнить зарплаты удалёнщиков и офисных сотрудников за 2019 год и дальше делать это ежегодно. Так мы сможем отследить тенденцию в разнице зарплат и увидеть, в каком же городе выгоднее работать удалённо, а в каком — в офисе.

Для исследования взяли данные, оставленные в калькуляторе зарплат Хабр Карьеры за последний год. Кстати, если вы ещё не оставляли свою зарплату в 2020 году, приглашаем вас это сделать.

Я уверен, где-то существует книга «Как подсидеть тимлида». Она передается из рук в руки, из команды в команду и содержит советы типа: «Тимлид никогда не уволится по своей воле, потому что это не работа, а сказка! Его нужно сломать», или «Если ваш тимлид уехал в отпуск, напишите ему, что вам нужно поговорить, когда он вернется. Пусть вместо серфинга думает, что в его отсутствие команда разбежалась», а еще «Саботируйте попытки тимлида внедрить новые полезные рабочие процессы фразой из Agile-манифеста о том, что люди и взаимодействие важнее процессов и инструментов». Иначе просто невозможно объяснить, почему все тимлиды сталкиваются с одними и теми же проблемами и страхами.

Я опросил более 400 тимлидов, чтобы провести деконструкцию некоторых из страхов тимлидов. Результаты опроса и исследование рынка тимлидов помогло понять, как с ними справиться, и я хочу поделиться результатами. Простые лайфхаки помогут меньше страдать от синдрома самозванца не только тимлидам, но и вообще любым специалистам, которые еще недавно выполняли конкретные задачи, а теперь руководят командой исполнителей.

Часто, когда я говорю кому-то про уязвимость, на меня смотрят как на сумасшедшего с табличкой «Покайтесь, ибо конец света близок»!

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

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

В Яндекс.Такси из двух вариантов выбрали третий — с помощью машинного интеллекта создать техподдержку с человеческим лицом. Меня зовут Татьяна Савельева, моя группа занимается машинным обучением на неструктурированных данных. Под катом — делюсь пользовательскими инсайтами, рассказываю как автоматизировать сложный процесс, организовать работу совершенно разных команд и, конечно же, применить на практике Deep learning и технические хаки (куда без них).

Berkeley Packet Filters (BPF) — это технология ядра Linux, которая не сходит с первых полос англоязычных технических изданий вот уже несколько лет подряд. Конференции забиты докладами про использование и разработку BPF. David Miller, мантейнер сетевой подсистемы Linux, называет свой доклад на Linux Plumbers 2018 «This talk is not about XDP» (XDP – это один из вариантов использования BPF). Brendan Gregg читает доклады под названием Linux BPF Superpowers. Toke Høiland-Jørgensen смеется, что ядро это теперь microkernel. Thomas Graf рекламирует идею о том, что BPF — это javascript для ядра.

На Хабре до сих пор нет систематического описания BPF, и поэтому я в серии статей постараюсь рассказать про историю технологии, описать архитектуру и средства разработки, очертить области применения и практики использования BPF. В этой, нулевой, статье цикла рассказывается история и архитектура классического BPF, а также раскрываются тайны принципов работы tcpdump, seccomp, strace, и многое другое.

Разработка BPF контролируется сетевым сообществом Linux, основные существующие применения BPF связаны с сетями и поэтому, с позволения @eucariot, я назвал серию "BPF для самых маленьких", в честь великой серии "Сети для самых маленьких".

Год назад я понял, что хочу создать собственный кластер Kubernetes. Я — разработчик программного обеспечения. Обычно я либо использую локальный кластер, состоящий из одного узла, либо применяю удалённый многоузловой кластер для тестирования своих проектов. В случае работы с кластером, состоящим из одного узла, я обычно полагаюсь на Minikube, хотя тут есть и другие решения, вроде проекта Kind, который может эмулировать наличие в кластере нескольких узлов. Поддержка нескольких узлов может появиться и в Minikube.

Итак, мне хотелось, чтобы в моём распоряжении оказались бы возможности обеих вышеупомянутых сред. То есть — чтобы у меня был бы и кластер, состоящий из нескольких узлов, и чтобы при этом работа с этим кластерам не подразумевала бы сетевых задержек, характерных для взаимодействия с удалёнными окружениями.



Уже написано множество замечательных руководств, посвящённых созданию многоузловых кластеров Kubernetes с использованием одноплатных компьютеров. Во многих из таких руководств в роли SBC применяется Raspberry Pi. Я, видя это, решил пойти по пути наименьшего сопротивления и тоже остановил свой выбор на этом компьютере. Платформа Raspberry Pi зарекомендовала себя как недорогое и доступное решение.

Надо отметить, что выбор этой платформы предусматривает некоторые компромиссы. Например, Broadcom и Raspberry Pi Foundation не лицензировали криптографические расширения ARMv8 (это нужно для аппаратного ускорения поддержки AES). Ещё одним неоднозначным решением является использование microSD-карт в виде стандартного носителя информации, с которого загружается операционная система.

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

Она стала мировой сенсацией. Её использовали в Fallout. Она помогла созданию отрасли кибербезопасности. Но откуда же она взялась?

«Это неинтересно», — думал Дэн Тейтел.

В Fallout 3 есть куча компьютерных терминалов, и если игрок хотел взломать один из них, ему нужно было победить в мини-игре, абстрактно представляющей процесс хакинга. Тейтел, работавший в 2007 году программистом Fallout в компании Bethesda, отвечал за реализацию дизайна этой мини-игры, и он считал, что игроки её возненавидят. «В ней использовались появляющиеся на экране буквы и таймер обратного отсчёта — ещё одна мини-игра, которую геймеры бы назвали скучной и назойливой. Я не был гейм-дизайнером, но считал своим долгом каким-то образом усовершенствовать эту идею».

Спустя несколько дней, по-прежнему не сумевший придумать ничего лучшего Тейтел получил электронное письмо от своего друга Боба. «Оно показалось мне потрясающим даром богов… я открыл письмо с сообщением „Привет, помнишь это?“ и ссылкой на онлайн-версию игры Mastermind».

Тейтел был на седьмом небе от счастья. Mastermind станет интересной игрой.


В этом году настольной игре Mastermind, посвящённой взлому кодов, исполняется 50 лет. Но на самом деле она старше, и никто не знает, насколько. Иронично то, что это игра про взлом кодов, источники происхождения обнаружить не удалось.

На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).

Ее основными тезисами были:

• GitFlow противоречит тезису "ветки должны быть короткоживущими".
  Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
• GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
  Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
• GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
• GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)

• Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.

  
  

  Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.

  
  

Так что делать-то?

В конце прошлого года мы выпустили .NET Core 3.0 и 3.1. В этих версиях добавлены модели настольных приложений Windows Forms (WinForms) и WPF, ASP.NET Blazor для создания одностраничных приложений и gRPC для кроссплатформенного обмена сообщениями на основе контрактов. Мы также добавили шаблоны для создания сервисов, крутое генерирование клиентского кода для общения с gRPC, сервисы REST API и многое другое. Мы рады, что .NET Core 3 стала самой быстро-принятой версией .NET, и за последний год у нас появился еще миллион пользователей.

Мы также работали над этими выпусками, чтобы завершить перенос моделей приложений из .NET Framework. В .NET Core 3 мы перенесли все наиболее используемые модели приложений, а также представили новые кроссплатформенные инфраструктуры вместо тех, которые не были портированы.

В ожидании следующего основного выпуска .NET 5 мы продолжим объединять .NET в единую платформу, включив нашу модель приложения для мобильных устройств .NET (Xamarin) в .NET 5. .NET 5 будет включать ASP.NET Core, Entity Framework Core, WinForms, WPF, Xamarin и ML.NET. Впервые вся платформа будет использовать унифицированный BCL (библиотеки базовых классов) для всех моделей приложений. Наличие версии 5, которая выше, чем у .NET Core и .NET Framework, также дает понять, что .NET 5 — это будущее .NET, единой унифицированной платформы для создания приложений любого типа.

Мы говорили это много раз, но мы еще раз повторим; .NET Core, а затем .NET 5 — это .NET, с помощью которого вам стоит создавать все свои новые приложения. .NET Framework будет поддерживаться до тех пор, пока поддерживается сама Windows. Мы будем продолжать обеспечивать безопасность и исправлять ошибки, а также обновлять сетевые и крипто API. Он будет оставаться безопасным и поддерживаться для работы ваших старых приложений на .NET Framework.

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

Привет, Хабр! Представляю вашему вниманию адаптированный перевод статьи «Deep Sky Objects and Their Observation» с любезного резрешения автора.

Интересная статья, классифицирующая объекты Deep-Sky, описывающая их разную природу образования. Также данная публикация дает крайне ценную информацию по методам наблюдения подобных космических объектов. В данном материале, автор делится своими личными впечатлениями о наблюдении столь завораживающих объектов как всевозможные туманности.

Интересного ознакомления, друзья!

Здравствуйте, дорогие друзья. Сегодня поговорим о более тяжелой артиллерии в рамках OSINT, а именно, о применении технологии распознавания лиц от Social Links для Maltego.


Если не читали предыдущие статьи цикла о Maltego, то сейчас — самое время:

• Часть 1 — Что такое Maltego и зачем оно вообще нужно
• Часть 2 — Интерфейс и базовое устройство
  
• Часть 3 — Maltego и OSINT в Facebook
• Часть 4 — Maltego и OSINT в ВК, Instagram, LinkedIN и других соцсетях

Во время тестирования функционала по поиску информации в различных соцсетях с применением Maltego (см. Часть 4) я удивился тому, что всего лишь по ФИО и фото из аккаунта в Инстаграм Maltego с ходу нашла мой аккаунт в LinkedIN.

Вот тут-то, я полагаю, и сработал механизм Face Recognition от Social Links. Мимо такой темы нельзя просто так взять и пройти! Нужно убедиться, насколько функционал точен и можно ли его применять полноценно в OSINT, или мой случай — единичный, а выдача будет забита похожими людьми.

В копилке Plarium Krasnodar набралось много интересных материалов, и мы хотим поделиться примечательными, на наш взгляд, примерами нарративного дизайна, связанного с проектированием пользовательского взаимодействия (UX) и графического интерфейса (GUI).

Всем привет!

Продолжаем обзоры новостей свободного и открытого ПО и железа (и немного коронавируса). Всё самое главное про пингвинов и не только, в России и мире.