Как работают каналы (pipes) в Linux #linux
Каналы осуществляюь межпроцессное взаимодействие путем отправки данных из вывода одного процесса (stdout) на ввод другого (stdin).
Существуют односторонние каналы, где данные передаются в одном направлении — от писателя (генератора данных) к читателю (потребителю данных).
Концептуальный поток: Процесс A (stdout) → [КАНАЛ] → (stdin) Процесс B

Некоторые типы каналов
1) Анонимные каналы
Представляют временный, односторонний канал связи между двумя связанными процессами.
Являются односторонними: Данные передаются в одном направлении.
Область видимости: Существует только во время выполнения процессов.
Создание: Создается программно с помощью системного вызова pipe() или неявно с помощью оператора | в командной строке.
Использование: Обычно используется для объединения команд в конвейер.

ПРимер создания канала:
$ cat file.txt | grep "keyword" | wc -l

Здесь cat читает файл. Вывод фильтруется grep.
Отфильтрованные строки подсчитываются с помощью wc.

2)Именованные каналы или Named Pipes (Также известны как FIFO (First In, First Out))
Представляют постоянный канал связи, который существует как специальный файл в файловой системе, позволяющий несвязанным процессам общаться.
Являются односторонними: Как в анонимных каналах, данные передаются в одном направлении.
Постоянство: Остается в файловой системе до явного удаления.
Создание: Создается с помощью команд mkfifo или mknod.
Область видимости: Может быть доступен через разные сеансы или несвязанные процессы.

Создание именованного канала:
$ mkfifo my_pipe

Запись в канал:
$ echo "Hello, World!" > my_pipe &

Считывание из канала:
$ cat < my_pipe


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

(Иллюстрация к предыдущему посту - Как работают каналы в Linux)

Зависимости основных сетевых протоколов

Дорожная карта для изучения технологий по работе с данными #database

Компоненты MAC-адреса

15 апреля 2025 года состоялся релиз Fedora Linux 42 (c GNOME 48/KDE Plasma 6.3, ядро Linux 6.14, Golang 1.24, LLVM 20, GCC 15, PHP 8.4, Ruby 3.4, GNU Binutils 2.44, GNU C Library 2.41, GDB 15, Tcl/Tk 9.0, IBus 1.5.32, Haskell GHC 9.8, Stackage 23, Django 5.x и Ansible 11), включая сборки Server и Workstation для архитектуры x86_64, Power64 и ARM64 (AArch64).
Сборка Fedora Workstation теперь включает долгожданный установщик Anaconda WebUI по умолчанию, а сборка Fedora KDE Plasma Desktop получила статуса базовой редакции дистрибутива, идентичной по уровню поддержки с Fedora Workstation
Рабочий стол в Fedora Workstation обновлён до ветки GNOME 48. Обновлены рабочие столы Xfce 4.20 и LXQt 2.1. Объединено содержимое каталогов /usr/bin и /usr/sbin. Добавлены новые группы flatpak и diskadmin для обеспечения доступа непривилегированных пользователей к функциям управления системными пакетами
Подробнее все изменения: https://fedoramagazine.org/announcing-fedora-linux-42/

Начато добавление материалов про созданию графических приложений на Vulkan на языке программирования С++
https://metanit.com/cpp/vulkan/1.1.php
#cpp

Шпаргалка по сегментации памяти

Краткая шпаргалка по наиболее распространенным командам в Linux #linux

Наглядно процесс разрешения DNS

Вышла новая версия Ubuntu - 25.04 "Plucky Puffin" (перевод - Отважный Тупик) на базе ядра Linux 6.14 и рабочего окружения GNOME 48.
Эта версия является промежуточной (не LTS) и будет поддерживаться до января 2026 года.
В новой версии разработчики найдут новые версии технологий и языков прогарммирования - GCC 15 (снапшот будущего релиза), LLVM 20, Python 3.13.3, Go 1.24, Rust 1.84,.NET 9.0, PHP 8.4, Ruby 3.3, OpenJDK 24, PostgreSQL 17, Valkey (форк Redis) 8.0.2, MySQL 8.4.4, Qt 6.8.3
Ряд других изменений:
ядро Linux обновлено до выпуска 6.14;
рабочий стол обновлён до выпуска GNOME 48
обновлены приложения: GIMP 3.0, LibreOffice 25.2, Firefox 137, Thunderbird 128;
обновлены серверные пакеты: Nginx 1.26.3, Apache httpd 2.4.63, OpenSSH 9.9, cloud‑init 25.1.1, Docker 27.5.1, Containerd 2.0.2, libvirt 10.10.0, ClamAV 1.4.2, OpenLDAP 2.6, QEMU 9.2.0 и т.д;
задействован пакетный менеджер APT 3.0;

Все изменения и дополнительная информация по релизу https://discourse.ubuntu.com/t/plucky-puffin-release-notes/48687

Искусственный интеллект способен заменить половину чиновников, считает глава Минцифры РФ Максут Шадаев. При этом он уточнил, что человека, особенно врачей и учителей, нейросети все же не заменят. Это заявление Шадаев сделал в ходе профильного мероприятия First Russian Data Forum.
«Человека, надеемся, он не заменит, особенно врачей и учителей. Считаю, что половину чиновников точно может заменить. Может, чуть больше», — пояснил Шадаев.
https://tass.ru/ekonomika/23708211

Процесс работы архитектуры микросервисов:

🔹 Клиентский уровень: веб-приложения, мобильные приложения или приложения для настольных компьютеров инициируют запросы пользователей.

🔹 CDN + Статический контент: быстрее доставляет статические ресурсы, такие как HTML, CSS и JS, кэшируя их ближе к пользователям.

🔹 Балансировщик нагрузки: равномерно распределяет трафик между несколькими экземплярами, чтобы обеспечить доступность и предотвратить перегрузки.

🔹 API-шлюз (API Gateway): действует как центральная точка входа, обеспечивая маршрутизацию, аутентификацию и ограничение скорости клиентских запросов.

🔹 Поставщик удостоверений (Identity Provider): аутентифицирует пользователей и выдает защищенные токены (например, OAuth или JWT) для управления доступом.

🔹 Микросервисы: Независимые сервисы, каждый из которых обрабатывает отдельную бизнес-функцию, организованную по домену. Их можно создавать, масштабировать и развертывать независимо.

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

🔹 Координация сервисов: поддерживает синхронизацию между сервисами и управляет распределенными конфигурациями (такие инструменты, как Zookeeper).

🔹 Брокер сообщений: обеспечивает асинхронную связь между сервисами с использованием очередей, таких как Kafka или RabbitMQ, — идеально подходит для разделения рабочих процессов.

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

Анимация к предыдущему посту

Как работают почтовые протоколы

Компании «Группа Астра», Axiom JDK и Haulmont представили OpenIDE — новую среду разработки с открытым исходным кодом. Решение ориентировано на госсектор и крупный бизнес. Для вывода платформы на рынок учредили совместную компанию — ООО «Открытая среда разработки».
Платформа основана на IntelliJ IDEA Community Edition. Первая версия сейчас находится на финальной стадии бета‑тестирования. В состав OpenIDE входит Axiom JDK — российская реализация JDK, доступная для промышленного использования. Также в решение добавлен бесплатный плагин Amplicode от Haulmont, предоставляющий базовую поддержку Spring. «Группа Астра» планирует добавить в OpenIDE интеграцию с платформой GitFlic.
В платформе нет проприетарных компонентов, а сервера с дистрибутивами и исходным кодом, как и команда, которая занимается ее сборкой, развитием и сопровождением, находятся в России. Также планируется добавить в платформу открытый маркетплейс, где будет поддержка российских плагинов.
https://astra.ru/about/press-center/news/openide-novaya-otechestvennaya-sreda-razrabotki-dlya-nadezhnykh-i-bezopasnykh-it-proektov/

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

🔹 SemVer использует трехкомпонентный номер версии: MAJOR.MINOR.PATCH.

- Старшая версия (MAJOR): увеличивается при наличии несовместимых изменений API.
- Младшая версия (MINOR): увеличивается при добавлении функциональности с сохранением обратной совместимости.
- Версия патчей (PATCH): увеличивается при внесении обратно совместимых исправлений ошибок.

🔹 Пример рабочего процесса
1 — Начальная фаза разработки
Начинаем с версии 0.1.0.

2 - Первый стабильный релиз
Выпуск стабильной версии: 1.0.0.

3 - Последующие изменения
Выпуск патча: Требуется исправление ошибки для 1.0.0. Обновите до 1.0.1.
Второстепенный релиз (увеличиваем младшую версию): новая, обратно совместимая функция добавлена ​​в 1.0.3. Обновление до 1.1.0.
Основной релиз (увеличиваем старшую версию): В версии 1.2.2 введено существенное изменение, несовместимое с предыдущими версиями. Обновление до версии 2.0.0.

4 - Специальные версии и предварительные релизы
Предварительные версии: 1.0.0-alpha, 1.0.0-beta, 1.0.0-rc.1.
Метаданные сборки: 1.0.0+20130313144700.

Иллюстрация к предыдущему посту про сематическое версионирование

Краткая шпаргалка по регулярным выражениям

6 базовых архитектурных паттернов

Тестирование API вносит значительный вклад в обеспечение надежности, безопасности, функциональности и эффективности приложений за счет оценки маршрутов связи между компонентами программного обеспечения.
Рассмотрим 6 наиболее распростраенных форм тестирования API:

🔹 Тестирование рабочего процесса (Workflow Testing)
Проверяет, правильно ли работает последовательность вызовов API для завершения определенного процесса.
Часто такие тесты рабочего процесса связаны с какой-либо бизнес-целью, например, с совершением покупки на платформе электронной коммерции.

🔹 Тестирование производительности (Performance Testing)
Он оценивает скорость, отзывчивость и стабильность API в различных условиях, чтобы убедиться, что он соответствует контрольным показателям и ожиданиям пользователей.
Он оценивает ключевые факторы, такие как скорость обработки, использование памяти, нагрузка на соединение, время отклика и пропускная способность сети, чтобы выявить потенциальные узкие места.
Цель состоит в том, чтобы убедиться, что система выдает ожидаемые ответы в разумные сроки, даже при различных уровнях нагрузки.

🔹 Тестирование безопасности (Security Testing)
Выявляет уязвимости, которые потенциально могут привести к несанкционированному доступу или утечке данных.
Он включает в себя строгие проверки, чтобы гарантировать, что меры безопасности достаточно надежны, чтобы предотвратить атаки и утечки данных.
Он использует такие методы, как тестирование на проникновение (penetration testing) и нечеткое тестирование (fuzz testing) для выявления уязвимостей. В качестве отправной точки можно начать со списка безопасности API OWASP.

🔹 Тестирование на основе данных (Data-driven Testing)
Передает различные наборы и типы входных данных в API, чтобы гарантировать его корректную работу в различных сценариях.
Он включает в себя использование таблицы входных данных, сопоставленных с ожидаемыми выходными данными, прогон этих входных данных через систему и проверку того, соответствуют ли фактические выходные данные ожидаемым результатам.

🔹 Тестирование конечной точки (Endpoint Testing)
Проверяет, правильно ли отдельные конечные точки API реагируют на запросы и возвращают ли ожидаемый ответ, данные, коды состояния и сообщения об ошибках.

🔹 Тестирование контракта (Contract Testing)
Проверяет, что взаимодействие между поставщиком API и потребителем соответствует предопределенному соглашению / контракту, включая ожидаемые структуры запросов, форматы ответов и типы данных.
Его основная задача — гарантировать, что поставщик API не вносит критических изменений, которые могут повлиять на потребителей, использующих API.