Linux *

Занимался я недавно портированием одного старого win32 MFC MDI приложения, до сих пор разрабатываемого с использованием Microsoft Visual Studio 6.0 (среда разработки 1998 года выпуска), на Linux. При чем необходимо было, чтобы под Linux собирался нативный бинарник в формате ELF из исходников. Взгляд упал на проект Wine, позволяющий запускать бинарники Windows (формат PE - Portable Executable). Один из компонентов Wine - библиотека Winelib - является прослойкой (враппером) между вызовами win32 и вызовами библиотек Linux. С помощью Winelib можно под Linux собирать win32 приложения из исходников. В составе Winelib есть десятки врапперов стандартных библиотек Windows. Но вот незадача. Враппера для MFC (Microsoft Foundation Classes) нет. В итоге прослойку между классами MFC и вызовами win32, пригодную для компиляции с использованием Winelib, пришлось готовить самому. Далее будет описан путь к решению задачи, а также компромиссы, на которые пришлось пойти по ходу реализации.

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

Алексей Учакин, спикер Слёрма по направлению «Сети для DevOps», поделился своим мнением и ответил на насущный вопрос: «Быть или не быть профессии сетевого инженера».

В нынешней ситуации многие сервисы блокируют доступ из РФ, я покажу как можно обойти этот запрет с помощью ProxyChains и Tor на примере MongoDB.

Привет, Хабр! Меня зовут Александр Копылов. Я руководитель направления, участник профсообщества Сбера DWH/BigData.

Сегодня предлагаю обсудить интересное решение из сферы инфобеза для высоконагруженных проектов. Огромное их количество, помимо технических возможностей и разнообразных фич, требует правильного подхода к безопасности. Одно из оптимальных решений ― FreeIPA, о нём и поговорим под катом.

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

Я часто заморачиваюсь на тему минимизации размера своих GUI приложений. Прошлая моя статья была про Nuklear. Но сейчас захотелось более современных технологий. Чтоб HTML5, CSS3 и PHP. Чтоб приложение ни от чего не зависело, т.е. построено по принципу "всё включено". И чтоб конечный размер приложения не превысил 2 МБ. Получится ли?

В Linux я часто пользуюсь утилитой df. Мне её очень не хватает в Windows, а искать аналоги лень. Так что было сделано волевое решение сделать свою, на РНР 5, с бутстрапом и JQuery.

Практика CI/CD широко распространена в современном мире и представить ручной деплой у FAANG с их бесчисленными ежедневными изменениями просто невозможно. То же будет справедливо и для продуктовых компаний: десятки ручных деплоев в день вытянуть можно, но это потребует колоссальных ресурсов.

Освоить эту практику можно дома, в среде, где что-то сломать не страшно, ведь всегда можно начать все с самого начала. В этом гайде рассмотрим как развернуть и настроить Jenkins в Docker, как создать агентов для сборки, а еще запушим образ в приватный Nexus.

За два года с тех пор, как я опубликовал статью I want off Mr Golang's Wild Ride, она вновь и вновь всплывала на Reddit, Lobste.rs, на HackerNews и в других местах.

Всякий раз дискуссия выходит к одним и тем же ответам:

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

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

Но, по сообщениям некоторых пользователей, у программ, написанных на Go, течёт память. Issue-трекер языка Go на github по запросам «high memory usage», «memory leak», «out of memory» выдаёт сотни и тысячи тикетов. А в самом популярном вопросе на stackoverflow по словосочетанию «golang memory» автор пытается разобраться, почему потребление оперативной памяти в рантайме в 4 раза превышает количество реально сделанных аллокаций. Обращения, в которых люди рапортуют о перерасходе оперативной памяти в Go, стали массовым явлением.

Что же это — утечки памяти, вызванные программистскими ошибками, или ожидаемое поведение рантайма языка? Мы попытаемся разобраться в причинах этого явления и сформулировать общие рекомендации, которые помогут в отладке проблем с потреблением памяти.

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

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

Но, к счастью, существует и третий вариант — кооперативная многозадачность с помощью системного вызова select и его аналогов (poll, epoll и других). Он позволяет мультеплексировать несколько задач в одном потоке выполнения и в сущности является обычной синхронной программой. А потому никаких дополнительных трат процессорного времени и времени разработчиков не требуется.

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

Дабы исчерпать до дна тему сокетов в Python я решил изучить все возможные способы их использования в данном языке. Чтобы всех их можно было испытать и попробовать на зуб, были созданы 19 версий простого эхо-сервера: от примитивного использования класса socket до asyncio. Блокирующие и неблокирующие сокеты, процессы и потоки, select'ы и selector'ы, коллбеки и сопрограммы — все эти темы расположены в эволюционном порядке, чтобы один пример плавно перетекал в другой.

Отдельно разобрано появление асинхронности в Python. На примерах детально показано, как и зачем появились итераторы, из них — генераторы, сопрограммы. Ближе к концу построен учебный макет библиотеки asyncio с минимально необходимым кодом, чтобы любой (даже такой, как я) смог разобраться, как на самом деле устроена асинхронность, как там все внутри работает.

Пишу подробно, чтобы случайно чего не пропустить. Поэтому понятно должно быть всем.

Одной из проблем развития бортовых систем для автомобиля является создание качественного переносимого программного обеспечения, которое бы работало на бортовых системах разных автопроизводителей и могло быть скомпилировано под разные аппаратные и программные архитектуры. Несмотря на очевидную актуальность, задача осложнялась прежде всего тем, что большинство автопроизводителей предпочитало создавать собственные проприетарные операционные системы, что затрудняло создание переносимого программного обеспечения. Ситуация изменилась со стартом проекта Automotive Grade Linux (AGL), поддерживаемыми крупными компаниями такими как Toyota, Mazda, Suzuki, Ford и Mercedes Benz и производителями медиасистем (например, Panasonic). И в планах развития проекта Flutter на 2022 год обозначено развитие поддержки AGL как целевой платформы для приложений. В этой статье мы рассмотрим основные идеи создания переносимых приложений для AGL на Flutter.

OOM Killer — защитный механизм ядра Linux, призванный решать проблемы с нехваткой памяти. При исчерпании доступной памяти он принудительно «убивает» наиболее подходящий по приоритетам процесс, отправляя ему сигнал KILL. Сообщение об этом отображается в /var/log/syslog (Debian/Ubuntu) или /var/log/messages (Centos/Rhel).

Иногда OOM Killer может затрагивать важные процессы, нарушая работу проекта. Как исправить это, узнали у Сергея Юдина, инженера Southbridge. Ниже подробный кейс с примерами кода. 

Не так давно состоялся релиз PureBasic версии 6.00, в котором среди прочего добавлена поддержка ARM процессоров. В списке поддерживаемых платформ присутствует Raspberry PI, но вероятно должны поддерживаться и другие похожие одноплатные компьютеры. Мною была проверена работа на большинстве моделей Raspberry PI включая самую простую - Zero и топовую на текущий момент - 4B. На всех была установлена Raspberry Pi OS April 4th 2022. Как и ожидалось, PureBasic запустился и нормально работал на всех тестовых Raspberry PI.

Начало

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

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