Разработка в Linux:
От Кода до Релиза

Почему Linux — это и есть IDE. Переменные окружения, утечки памяти и как создать своего демона.

1. Философия UNIX

В Windows тебе нужна огромная Visual Studio на 20ГБ. В Linux твоя IDE — это сама операционная система. Здесь работает принцип: "Одна программа делает одну вещь, но делает её хорошо".

Все есть файл

Сокет, процесс, жесткий диск — для Linux это все файлы. Ты можешь прочитать данные с сетевой карты командой `cat`.

CLI — это сила

Ты можешь объединять утилиты в цепочки (Pipes) `|`. Вывод одной программы становится вводом другой.

2. Окружение (Environment)

Программы в Linux живут не в вакууме. Они живут в Окружении. Это набор переменных, которые говорят программе, где искать библиотеки, конфиги и другие программы.

  • PATH
    Самая важная переменная. Когда ты пишешь `python`, Linux ищет файл `python` в папках, перечисленных в PATH.
    export PATH=$PATH:/home/user/my_scripts
  • LD_LIBRARY_PATH
    Указывает, где искать динамические библиотеки (`.so`), если они лежат не в стандартных папках (`/usr/lib`).
  • Shebang (#!)
    Первая строка в скрипте (`#!/bin/bash` или `#!/usr/bin/env python3`). Она говорит ядру: "Эй, этот текстовый файл нужно выполнить вот этим интерпретатором".

3. Сборка (Compiling)

Компилировать один файл (gcc main.c) просто. Но реальные проекты — это тысячи файлов. Как этим управлять?

  • Make: Старая школа. Ты пишешь Makefile — инструкцию, как "печь пирог".
  • CMake: Современный стандарт. Это мета-система: она генерирует Makefile за тебя. Кроссплатформенная и мощная.

// Стандартный цикл сборки (Out-of-source build)

mkdir build && cd build
cmake .. # 1. Конфигурация (проверка компиляторов)
make -j4 # 2. Компиляция (в 4 потока)
make install # 3. Установка в систему

4. Зависимости (Hell)

В Linux программы часто используют Shared Libraries (.so). Это экономит память, но рождает проблему зависимостей.

Ошибка новичка: "Я установил `libssl`, но при компиляции получаю ошибку `openssl/ssl.h not found`".

Решение: Тебе нужен пакет libssl-dev (или -devel). В обычном пакете лежат только бинарники для *запуска*. В dev-пакете лежат заголовки (.h) для *компиляции*.

// Проверить, какие библиотеки нужны бинарнику (и каких не хватает)

ldd /usr/bin/nginx

5. Отладка (Sherlock Mode)

Если программа падает или "течет" память, у тебя есть три лучших друга.

GDB

Микроскоп. Пошаговое выполнение, просмотр переменных в RAM. Сложно, но мощно.

Strace

Рентген. Показывает, как программа общается с ядром (открытие файлов, сеть). Не требует перекомпиляции.

Valgrind

Аудитор. Запускает программу в виртуальной машине и ищет утечки памяти (Memory Leaks).

// Пример поиска утечек памяти с Valgrind

valgrind --leak-check=full ./my_cpp_app
==123== LEAK SUMMARY:
==123== definitely lost: 40 bytes in 1 blocks

6. Упаковка (Shipping)

Ты написал код. Как доставить его пользователю? Кликни на формат.

.DEB (Debian/Ubuntu)

Тип: Нативный системный пакет.

Используется в Ubuntu, Debian, Kali, Mint. Четко прописывает зависимости ("мне нужен libssl версии 1.1"). Если зависимости нет в системе — не установится. Максимальная интеграция с ОС.

7. Systemd & Logs

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

1. The Unit File

/etc/systemd/system/myapp.service

[Unit]
Description=My Super App
After=network.target # Ждать, пока поднимется сеть

[Service]
ExecStart=/usr/bin/myapp
Restart=always # Воскресить, если упадет
User=www-data # Запускать от безопасного юзера
Environment="PORT=8080"

[Install]
WantedBy=multi-user.target

2. Чтение логов (Journalctl)

Systemd перехватывает все, что ваша программа пишет в консоль (stdout/stderr), и сохраняет в бинарный журнал.

// Смотреть логи моего сервиса в реальном времени

journalctl -u myapp.service -f