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

(Ключ -p автоматически создаст все промежуточные каталоги, если их нет).

Монтируем удаленную директорию Синтаксис предельно простой:

Например, если я хочу примонтировать каталог My-folder с удаленного сервера (IP: 192.168.1.6) в свою созданную папку, команда будет выглядеть так:

После монтирования можно проверить результат командой df -h. Теперь вы можете копировать, удалять, редактировать файлы в IDE или просматривать логи прямо в примонтированной папке. Все изменения моментально происходят на сервере.

Важные нюансы (чтобы не отваливалось) У SSHFS есть особенность: если интернет моргнет, примонтированная папка может намертво зависнуть. Чтобы этого избежать, рекомендую монтировать с параметрами поддержания сессии:

(Эта опция будет каждые 15 секунд отправлять ping-пакет на сервер, не давая соединению разорваться).

Как размонтировать? Когда работа закончена, директорию нужно отмонтировать. Так как мы монтировали без прав суперпользователя, обычный umount может выдать ошибку прав. Правильнее использовать эту команду:

(Если получаете ошибку «устройство занято», убедитесь, что вы закрыли все файлы из этой папки и сами вышли из директории в терминале).

Используете ли вы SSHFS в повседневной работе или предпочитаете другие инструменты? Пишите в комменты.

Больше подобных шпаргалок, команд и коротких заметок по Linux и администрированию серверов я регулярно публикую в своем Telegram-канале [Linux для Админов и DevOps]. Буду рад видеть там коллег по цеху, заходите!

Долгое время операционные системы семейства Windows считались единственным неоспоримым стандартом для компьютерных игр. Однако развитие слоя совместимости Proton от Valve и появление узкоспециализированных игровых дистрибутивов изменили положение дел.

Сегодня CachyOS (дистрибутив на базе Arch Linux) не просто предлагает альтернативу, а в целом ряде сценариев опережает Windows 10 и 11 по среднекадровому FPS, плавности графика (1% и 0.1% Low) и отзывчивости ввода.

Ниже приведен подробный разбор технических причин и архитектурных особенностей, за счет которых CachyOS демонстрирует более высокую игровую производительность и комфорт.

1. Агрессивная компиляция под инструктивные сеты процессоров (x86-64-v3 / v4)

Главный системный недостаток Windows — необходимость сохранять совместимость с любым x86-64 процессором, выпущенным за последние 15–20 лет. Из-за этого Microsoft и разработчики ПО под Windows вынуждены компилировать бинарные файлы под базовый стандарт x86-64-v1.

Как это решено в CachyOS:

• Инструкции x86-64-v3 и v4: Репозитории CachyOS пересобраны с флагами оптимизации под современные векторные инструкции процессоров (AVX2, AVX-512, FMA, BMI2).

• Оптимизации компилятора (GCC/Clang): Все системные библиотеки, драйверы и ядро скомпилированы с применением LTO (Link-Time Optimization), PGO (Profile-Guided Optimization) и максимального уровня оптимизаций -O3.

• Результат: Процессор выполняет математические расчеты физики, геометрии и обработку игрового логического потока за меньшее количество тактов, что дает прямой прирост производительности на современных CPU (AMD Ryzen, Intel Core 10+ поколений).

2. Ядро linux-cachyos и специализированный планировщик BORE

В традиционных ОС планировщик задач делится ресурсами процессора по принципу «равного распределения» (например, планировщик EEVDF в базовом ядре Linux или универсальный планировщик Windows).

Преимущество CachyOS:

CachyOS использует кастомное ядро с планировщиком BORE (Burst-Oriented Response Enhancer):

• Приоритет интерактивным задачам: BORE распознает игровые процессы и графические потоки как приоритетные, моментально выделяя им кванты времени CPU и отдавая фоновые задачи на второстепенные потоки.

• Минимизация микрофризов: Статтеры и резкие просадки кадров при загрузке локаций или спавне врагов происходят тогда, когда поток отрисовки ждет ответа от CPU. Планировщик BORE сведет задержку вызова (latency) к минимуму, гарантируя более ровный график времени кадра (Frametime) и высокие показатели 1% и 0.1% Low FPS.

3. Минимальные накладные расходы и отсутствие фонового «шума» (Bloatware)

Windows 11 в простое представляет собой сложный кошмар из сотен системных служб: за защитой отвечает Defender, ресурсы забирают Telemetry, Copilot, Widget Service, фоновые обновления, Xbox Game Bar и индексаторы диска.

Сравнение с CachyOS:

• Расход ОЗУ: Windows 11 потребляет от 3.5 до 5.5 ГБ оперативной памяти сразу после загрузки. CachyOS расходует ~1–1.5 ГБ (с графическим окружением KDE Plasma), оставляя оставшийся объем под текстуры и контекст игры.

• Прерывания CPU: В CachyOS отсутствуют фоновые сервисы сборки метрик или скрытой сканирующей проверки дисков. Каждая секунда процессорного времени отдается непосредственно игре, драйверу и Vulkan/Proton транслятору.

4. Графический стек: Mesa (RADV), Proton-CachyOS и NTSync / Fsync

Парадоксально, но трансляция вызовов DirectX (11/12) в Vulkan через Proton часто работает быстрее, чем нативный DirectX-пайплайн внутри Windows.

Ключевые компоненты:

1. Драйверы Mesa RADV (для AMD): Открытый драйвер RADV в Linux разрабатывается инженерами Valve и сообществом. Во многих играх он эффективнее обрабатывает шейдеры и распределяет видеопамять, чем проприетарный драйвер AMD Adrenalin для Windows.

2. Патчи NTSync / Fsync: В CachyOS встроен пропатченный стек proton-cachyos и wine-cachyos. Патчи синхронизации объектов (NTSync) заменяют медленные механизмы синхронизации ядра Windows (NT primitives) на прямые быстрые системные вызовы ядра Linux (futex). Это убирает узкое горлышко при взаимодействии многопоточного движка игры с процессором.

5. Доказательства и результаты реальных бенчмарков

Эффективность CachyOS подтверждается не только теорией, но и объективными независимыми тестами специализированных железо-порталов и блогеров:

• Превосходство в требовательных AAA-играх: Тестирование системы в реальных условиях показало, что CachyOS обходит Windows 11 в таких проектах, как Cyberpunk 2077 и Warhammer 40,000: Space Marine 2. В Space Marine 2 средний показатель кадровой частоты составил 81 FPS на CachyOS против 68 FPS на Windows 11, а показатель 1% Low поднялся с 58 до 72 FPS (ссылка на TechSpot).

• Сравнение стабильности и 1% Low: Портал XDA Developers отмечает, что благодаря оптимизациям Proton и системного ядра CachyOS демонстрирует прирост от 3% до 12% по среднему FPS и обеспечивают ощутимо более плавную картинку без рывков (ссылка на XDA Developers).

• Сводные бенчмарки Phoronix и TechPowerUp: В комплексном тестировании производительности системы на топовом железе CachyOS одержала победу более чем в 52% всех проведенных тестов, опередив как Windows 11, так и стандартные дистрибутивы вроде Ubuntu (ссылка на TechPowerUp).

6. Полный контроль, предсказуемость и современные технологии дисплея

Помимо чистого FPS, CachyOS предлагает лучший пользовательский опыт для игрового ПК:

• Никаких принудительных обновлений: Система никогда не начнет скачивать гигабайты обновлений во время сетевого матча и не перезагрузит ПК посреди важной сессии.

• Нативный Wayland и VRR / HDR: Состояние графического стека KDE Plasma на Wayland обеспечивает работу с несколькими мониторами с разной частотой обновления, поддержку Variable Refresh Rate (FreeSync/G-Sync) и HDR без задержек и композиторного «мыла», свойственного оконному режиму Windows.

7. Простая установка и централизованные обновления «в один клик» из трея

Распространенный миф гласит, что Arch Linux и дистрибутивы на его базе требуют сложных ручных настроек через консоль, а обслуживание системы превращается в головную боль. CachyOS полностью разрушает этот стереотип, предлагая уровень удобства, недоступный в Windows.

Плюсы обслуживания в CachyOS:

• Дружелюбный графический установщик: В отличие от ванильного Arch Linux, CachyOS поставляется с удобным инсталлятором Calamares и встроенной утилитой CachyOS Hello. Установка системы происходит графически в пару кликов мышкой: система сама разметит диск, установит нужные видеодрайверы (Nvidia или AMD) и подготовит рабочий стол под ключ.

• Единый центр обновлений без стороннего ПО: В Windows поддержание ПК в актуальном состоянии превращается в хаос: драйвер видеокарты обновляется через NVIDIA App / AMD Adrenalin, браузеры и лаунчеры обновляются сами по себе, а отдельные программы требуют постоянного ручного скачивания .exe-инсталляторов с сайтов.

• Обновления из системного трея: В CachyOS абсолютно всё софтверное окружение — ядро Linux, драйверы видеокарты, Vulkan-стек, системные библиотеки, Steam, браузеры и приложения — обновляется нажатием одной кнопки прямо из системного трея (через графический менеджер пакетов или апплет обновлений). Больше не нужно держать в фоне десятки сторонних утилит-апдейтеров или вручную искать новые версии драйверов в сети.

Итоговый вердикт

Складывая вместе компиляцию пакетов под инструкции x86-64-v3/v4, планировщик ядра BORE, чистый системный стек без фонового bloatware, высокооптимизированные драйверы Mesa / Proton-CachyOS, а также удобнейший графический установщик и централизованное обновление всех драйверов и программ одной кнопкой из трея, мы получаем операционную систему нового поколения.

CachyOS доказал, что Linux не просто догнал Windows в играх, но и превзошел ее как по чистой производительности и плавности кадра, так и по ежедневному удобству обслуживания ПК.

Всё. Теперь никто не может даже начать подключение. Сервер притворяется мертвым.

Устанавливаем и настраиваем knockd Ставим сам демон:

Обязательно делаем бекап дефолтного конфига:

Теперь открываем /etc/knockd.conf.

Важный нюанс: вам нужно указать свой сетевой интерфейс (например, eth0 или enp0s3) и заменить команду добавления правила с -A INPUT (добавить в конец) на -I INPUT 1 (вставить первым правилом), иначе фаервол его проигнорирует из-за предыдущих запретов.

Вот пример рабочего конфига:

Включаем автозапуск Открываем файл /etc/default/knockd, находим строчку START_KNOCKD=0 и меняем её на 1. Запускаем:

Как теперь заходить на сервер? (Стучим с клиента) На свой рабочий компьютер (клиент) тоже ставим утилиту:

Теперь, когда нам нужен доступ к серверу (допустим, его IP 192.168.1.6), мы сначала «стучим» правильную комбинацию:

Порт открылся для нашего IP. Спокойно заходим:

После завершения работы закрываем за собой дверь обратной комбинацией:

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

Надеюсь, кому-то эта шпаргалка сэкономит время. Я собираю подобные полезные сниппеты, команды и короткие мануалы по Linux и администрированию в свой Telegram-канал [Linux для Админов и DevOps]. Буду рад видеть там коллег по цеху, заходите!

Ода миниатюризации

Есть много причин, по которым миниатюрные девушк.. ээ реализации программ заслуживают внимания:

• обучение — врядли получится разобраться как устроен вебсервер, перелопачивая исходники монстров вроде Apache или Nginx, спасет только миниатюрная реализация;

• основа для собственных проектов — большой объем чужого исходного кода под капотом вашего проекта будет висеть гирей и отвлекать ресурсы на поддержку, в отличие от чего-то маленького и простого;

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

Разумеется есть определенные риски использования таких «наколенных» библиотек, связанные с неполной реализацией, безопасностью, работой под нагрузкой и так далее.

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

Еще с опытом приходит понимание, что любая программа — не более чем инструмент а реальную опасность всегда представляют живые люди, а не тупые машины.

Тестовое окружение

Не стал опять заморачиваться с *BSD, чтобы в третий раз не описывать специальную прослойку epoll-shim, позволяющую быстро и более-менее безболезненно портировать серверный софт с линукса. На этот раз в качестве тестового окружения выступает обычная Ubuntu Linux 25.10, хотя и с немного нестандартным ядром.

Компилятором выступит штатный же GCC, без изысков:

gcc version 15.2.0 (Ubuntu 15.2.0-4ubuntu4)

Sandbird

https://github.com/rxi/sandbird

Начнем погружение с весьма практичного проекта:

A tiny (~800sloc) embeddable HTTP server written in C89, compatible with Linux, OSX and Windows.

800 строк на чистом С, причем наиболее портабельного стандарта С89, c поддержкой Windows, Linux и MacOS — отличный набор для реального применения, например в качестве встроенного вебсервера для WiFi-роутера.

Один из примеров, демонстрирующих работу этой библиотеки — на заглавном скриншоте к статье, причем показана обработка вебформы.

Вот так выглядит сборка примера:

cd example
gcc hello.c ../src/*.c -I../src -std=c89 -pedantic -Wall -Wextra -o hello

Так выглядит код тестового приложения с использованием этой библиотеки:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "sandbird.h"

static int event_handler(sb_Event *e) {
if (e->type == SB_EV_REQUEST) {
printf("%s - %s %s\n", e->address, e->method, e->path);
sb_send_status(e->stream, 200, "OK");
sb_send_header(e->stream, "Content-Type", "text/plain");
sb_writef(e->stream, "Hello world");
}
return SB_RES_OK;
}

int main(void) {
sb_Options opt;
sb_Server *server;

memset(&opt, 0, sizeof(opt));
opt.port = "8000";
opt.handler = event_handler;
server = sb_new_server(&opt);

if (!server) {
fprintf(stderr, "failed to initialize server\n");
exit(EXIT_FAILURE);
}
printf("Server running at http://localhost:%s\n", opt.port);

for (;;) {
sb_poll_server(server, 1000);
}
sb_close_server(server);
return EXIT_SUCCESS;
}

Важный нюанс:

сервер не использует многопоточность, все клиентские обработчики работают в одном потоке.

зато с неблокирующими сокетами:

..
static void set_socket_non_blocking(sb_Socket sockfd) {
#ifdef _WIN32
u_long mode = 1;
ioctlsocket(sockfd, FIONBIO, &mode);
#else
int flags = fcntl(sockfd, F_GETFL);
fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);
#endif
}
..

webs

https://github.com/nicholascok/webs

Следующий интересный и даже в чем-то уникальный проект, с лаконичным описанием:

a simple websocket server library.

Реализует с помощью ~700 строк на С89.. серверные вебсокеты!

Вебсокеты это чаты, это «live-streaming», это например отображение логов в реальном времени и тому подобные динамические штуки.

Так это выглядит в действии:

Так выглядит сборка тестового приложения:

gcc -c *.c examples/test.c -Wall -Wextra -Wpedantic -Wno-overlength-strings -std=c89
gcc -o webs *.o -lpthread

Как нетрудно догадаться по -lpthread, тут уже используется многопоточность на базе POSIX threads:

..
static void* __webs_main(void* _srv) {
webs_server* srv = (webs_server*) _srv;
webs_client* user_ptr;
webs_client user;

for (;;) {
user.fd = __webs_accept_connection(srv->soc, &user);
user.srv = srv;
if (user.fd >= 0) {
user_ptr = __webs_add_client(srv, user);
pthread_create(&user_ptr->thread, 0, __webs_client_main,
user_ptr);
}
}
return NULL;
}
..

К сожалению этот интересный проект по большей части прототип, иллюстрирующий как можно на коленке без внешних библиотек реализовать серверную сторону вебсокетов на чистом С.

В случае реального использования, столь вольное использование malloc для обработки входящих пакетов быстро превратится в проблему:

..
/* deal with normal frames (non-fragmented) */
if (WEBSFR_GET_OPCODE(frm.info) != 0x0) {
/* read data */
if (data) free(data);
data = malloc(frm.length + 1);
..

Так выглядит сокращенная версия тестового сервера вебсокетов, c минимумом обработчиков:

#include "../webs.h"

int myFuncZ(webs_client* self) {
printf("server %ld: (id %ld) connected!\n",
self->srv->id, self->id);
webs_send(self, "greetings, salutations!");
return 0;
}
int myFunc2(webs_client* self) {
printf("server %ld: (id %ld) disconnected!\n",
self->srv->id, self->id);
return 0;
}
int main(void) {
webs_server* server1 = webs_start(7754);
if (!server1) {
printf("failed to initialise a server.\n");
return 1;
}
server1->events.on_open = myFuncZ;
server1->events.on_close = myFunc2;

webs_hold(server1);
webs_close(server1);
return 0;
}

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

Повторюсь, что весь этот проект, несмотря на всю свою интересность — сырой прототип и тащить в прод подобный код без переработки, "as-is" точно не стоит.

Собирается только для Linux и только с помощью gcc.

Прототип как он есть.

cpp-httplib

https://github.com/yhirose/cpp-httplib

Это уже куда более зрелая библиотека:

A C++ header-only HTTP/HTTPS server and client library

11к строк кода на C++11 и несколько зависимостей от внешних библиотек:

pthreads, brotli, OpenSSL, zlib

Реализуют весьма продвинутый HTTP/HTTPS сервер и клиент, причем фактически в одном файле. Есть поддержка сборки как на Linux так и Windows, причем для второй есть готовый проект для Visual Studio.

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

Так выглядит сборка тестового сервера, использующего эту библиотеку:

g++ -o server -O2 -std=c++11 -I.. -Wall -Wextra -pthread \
server.cc -DCPPHTTPLIB_OPENSSL_SUPPORT -lssl -lcrypto \
-DCPPHTTPLIB_ZLIB_SUPPORT -lz -DCPPHTTPLIB_BROTLI_SUPPORT \
-lbrotlicommon -lbrotlienc -lbrotlidec

По флагам вроде CPPHTTPLIB_ZLIB_SUPPORT можно заметить, что большая часть зависимостей на самом деле опциональна и отключаема.

Еще думаю, заблудиться в 11к строчках кода и одном единственном файле будет проблематично даже у нейросети не самых опытных «плюсолюбов».

Так выглядит серверный «Hello, world!»:

#include <httplib.h>
using namespace httplib;

int main(void) {
Server svr;

svr.Get("/hi", [](const Request & /*req*/, Response &res) {
res.set_content("Hello World!", "text/plain");
});

svr.listen("0.0.0.0", 8080);
}

Код в лучших традициях Django или Rails, тут есть маршрутизация запросов и привязка к URL — в данном случае обработчик связывается с урлом /hi.

Вот так выглядит обработка загрузки файлов с помощью формы и POST-запроса:

#include <fstream>
#include <httplib.h>
#include <iostream>
using namespace httplib;
using namespace std;

const char *html = R"(
<form id="formElem">
<input type="file" name="image_file" accept="image/*">
<input type="file" name="text_file" accept="text/*">
<input type="submit">
</form>
<script>
formElem.onsubmit = async (e) => {
e.preventDefault();
let res = await fetch('/post', {
method: 'POST',
body: new FormData(formElem)
});
console.log(await res.text());
};
</script>
)";

int main(void) {
Server svr;

svr.Get("/", [](const Request & /*req*/, Response &res) {
res.set_content(html, "text/html");
});

svr.Post("/post", [](const Request &req, Response &res) {
const auto &image_file = req.form.get_file("image_file");
const auto &text_file = req.form.get_file("text_file");

cout << "image file length: " << image_file.content.length() << endl
<< "image file name: " << image_file.filename << endl
<< "text file length: " << text_file.content.length() << endl
<< "text file name: " << text_file.filename << endl;
{
ofstream ofs(image_file.filename, ios::binary);
ofs << image_file.content;
}
{
ofstream ofs(text_file.filename);
ofs << text_file.content;
}

res.set_content("done", "text/plain");
});

svr.listen("localhost", 1234);
}

Так это выглядит в действии:

Разумеется подобный функционал — не откровение, особенно на 2026й год, но блин:

11к строк кода на всю красоту!

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

tiny_ftpserver

https://github.com/adamwym/tiny_ftpserver

Вот такой «игрушечный» проект:

a tiny FTP server written in C++

Всего 1.5к строк на С++11 от безвестного китайского автора реализуют полнофункциональный FTP/FTPS‑сервер — с chroot, поддержкой локальных и анонимных юзеров и всем прочим.

FTPS это довольно редко встречающееся расширение протокола FTP, с поддержкой шифрования передачи данных. Не набравшее большой популярности ввиду появления SFTP и органичений самого FTP и потому мало известное широкой админской публике.

В работе:

Проект использует известную библиотеку libnet, о чем автор забыл сообщить и которую необходимо установить до сборки:

apt install libnet1-dev

Сама сборка происходит с помощью обычного cmake:

mkdir build && cd build
cmake ..

Реализация FTP-сервера тут максимально классическая — используется chroot а использование 21 и 20 портов зашито в код:

..
int socketfd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, 0);
struct sockaddr_in server_addr;
memset(&server_addr, 0, sizeof(server_addr));
server_addr.sin_port = htons(21);
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = INADDR_ANY;
..

Все это означает, что запускать сервер придется от суперпользователя:

sudo ./tiny_ftpserver ../tiny_ftpserver.conf

У этого проекта есть один неожиданный нюанс:

на самом деле это.. студенческая работа.

И подобных проектов на Github оказалось великое множество. Так что далеко не везде в 2026м году забыли что такое высшее техническое образование, что не может не радовать.

fineFTP Server

https://github.com/eclipse-ecal/fineftp-server

Следующий интересный и весьма редкий проект:

FineFTP is a minimal FTP server library for Windows and Unix flavors.

~2k строк на С++14 реализуют FTP-сервер в виде.. библиотеки!

В этом и есть основная фишка этого проекта — возможность встроить FTP (причем сервер а не клиент) в ваше собственное приложение.

Так выглядит код примера, с внедрением FTP-сервера:

#include <fineftp/server.h>
#include <thread>

int main() {
// Create an FTP Server on port 2121. We use 2121 instead of the default port
// 21, as your application would need root privileges to open port 21.
fineftp::FtpServer ftp_server(2121);

// Add the well known anonymous user. Clients can log in using username
// "anonymous" or "ftp" with any password. The user will be able to access
// your C:\ drive and upload, download, create or delete files. On Linux just
// replace "C:\\" with any valid path. FineFTP is designed to be cross-platform.
ftp_server.addUserAnonymous("C:\\", fineftp::Permission::All);

// Start the FTP Server with a thread-pool size of 4.
ftp_server.start(4);

// Prevent the application from exiting immediately
for (;;) std::this_thread::sleep_for(std::chrono::milliseconds(100));
return 0;
}

Зачем и для чего такое может быть нужно — другой вопрос, все же обычно работу с файлами в конечном приложении (например обновление прошивки) стараются реализовать в виде клиента и через HTTP/HTTPS.

Но с точки зрения использования все отлично работает:

Это хорошая, взрослая библиотека, с несколькими коммитерами, с историей разработки, которая активно поддерживается и развивается.

Старого цирка с chroot и 21м портом тут нет, поэтому все работает без привилегий суперпользователя — на скриншоте выше как раз видно использование нестандартного порта для работы.

Поддерживается сборка для Linux, MacOS и Windows c приоритетом для последней.

Отличный проект, но далеко не последний в сегодняшней подборке.

rcpd

https://github.com/tenox7/rcpd

Этот проект — привет из далекого и славного прошлого:

This is a modern re-implementation of rcp (remote copy protocol) daemon, originally part berkeley r-commands.

Да, это самый настоящий сервер RCP, всего 300 строк на Golang от знаменитого в узких кругах компьютерных реконструкторов автора Tenox.

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

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

Возвращаясь к проекту:

rcpd от Tenox реализует серверную сторону — сервер RCP

К этому серверу подключаются клиенты для загрузки или скачивания файлов. Так выглядит процесс копирования файла, в качестве клиента тут rcp из пакета GNU Inetutils:

Как видите и клиент и сервер запускаются от суперпользователя — такие были времена, RCP использует 514 порт, который нельзя занять без привилегий.

Сборка:

go build -o rcpd .

Кстати в Makefile проекта есть поддержка кроссплатформенных сборок, с весьма богатым выбором:

Стоит добавить, что протокол RCP сам по себе очень простой и не менялся весь период своего существования, что позволяет подключаться к этому RCP-серверу 21 века даже с помощью клиентских программ из 80х и 90х.

За кадром

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

url.c

https://github.com/cozis/url.c/

Парсер строк URL на чистом С и без зависимостей:

This is a small library to parse and manipulate URLs in conformance to RFC 3986 and (most of) the WHATWG specification.

Что умеет:

• No allocations

• No dependencies

• The ability to switch between RFC 3986 and WHATWG with a flag

• Relative reference parsing and resolution

• URL normalization

• Doesn't rely on null-terminated strings

LightFTP

https://github.com/hfiref0x/LightFTP

Еще один интересный проект миниатюрного FTP-сервера:

Small x86-32/x64 FTP Server

Поддерживается сборка под Linux/Windows/Mac, сам проект не мертвый и судя по коммитам — развивается.

uftpserver

https://github.com/cpopp/MicroFTPServer

Весьма специфичная реализация FTP-сервера для встраиваемых систем:

Minimal FTP Server that can run on an ESP8266 with MicroPython

Так я впервые узнал о существовании «микропетона» — давно существующего проекта, с огромным количеством поддерживаемого железа и широким функционалом.

Ну и в качестве финального аккорда:

https://github.com/mtheall/ftpd

FTP Server for 3DS/Switch/Linux.

Реализация FTP-сервера для.. Nintendo Switch!

Это такая игровая консоль для гиков если кто вдруг не в курсе:

P.S.

Статья была опубликована на Хабре, оригинал как обычно в нашем блоге.

IPv6 здесь не заменяет клиентский IPv4 и не участвует в пользовательской адресации. Он только несёт UDP-пакеты WireGuard между двумя маршрутизаторами. Это удобное разделение: внешний транспорт живёт своей жизнью, а внутреннюю IPv4-маршрутизацию можно менять независимо.

При underlay MTU 1500 мы оставили WireGuard MTU 1420. Расчёт скучный, но полезный: IPv6-заголовок занимает 40 байт, UDP ещё 8, служебная часть WireGuard data packet — 32. Итого 80 байт накладных расходов, поэтому 1500 − 80 = 1420.

Как должен был идти трафик

На центральном роутере появилась отдельная FIB-таблица с default route через туннельный адрес удалённого RouterOS. Трафик Linux-хоста портала маркировался и отправлялся в эту таблицу. На удалённой стороне были обратный маршрут к сети портала, разрешение forward из туннеля в ISP и обычный masquerade на внешнем интерфейсе.

Мы отдельно проверили транспорт:

• WireGuard handshake обновлялся с обеих сторон;

• внутренние адреса туннеля пинговались в обоих направлениях;

• OSPF поднялся поверх WireGuard и установил ожидаемые маршруты;

• удалённый RouterOS сам успешно ходил во внешний IPv4;

• центральный роутер выбирал нужную policy table.

То есть сам IPv6 underlay и межроутерный WireGuard работали. Но клиентский трафик всё равно не возвращался.

Почему первые подозрения оказались неверными

Сначала мы сравнили рабочий egress через другой роутер и новый egress. Отличались rp-filter, форма правила masquerade и набор forward-правил. Эти отличия выглядели подозрительно, но после приведения настроек к рабочему шаблону симптом остался.

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

Два tcpdump и один route get

На Linux-хосте портала одновременно запустили захват на интерфейсе WireGuard и на LAN-интерфейсе.

На выходе всё выглядело правильно: пакет клиента приходил из WG-пула, пересылался в LAN и получал SNAT в адрес самого хоста. На LAN-интерфейсе были видны и запросы к внешнему адресу, и ответы обратно. Значит, удалённый RouterOS, NAT и интернет-маршрут свою работу уже сделали.

Но на wg-интерфейсе были только исходящие запросы клиента. Ответы доходили до Linux-хоста и дальше в туннель не попадали. Счётчик forward в направлении LAN → WireGuard тоже не рос.

Решающим оказался обычный поиск маршрута для реального ответного пакета. Ядро выбирало основной default route хоста, а не wg-интерфейс. Причина была простой: policy rule существовало только для пакетов от клиентского пула. Ответ из интернета приходит к клиентскому пулу, поэтому правило по source на него не распространяется.

Точечное исправление

В отдельной таблице уже был link route клиентской сети через wg-интерфейс. Не хватало симметричного правила выбора этой таблицы по адресу назначения:

ip rule add to <WG_CLIENT_POOL> lookup <VPN_TABLE> ip rule add from <WG_CLIENT_POOL> lookup <VPN_TABLE>

Первое правило возвращает ответы в WireGuard, второе сохраняет прежний исходящий policy routing. После добавления destination rule тот же route lookup выбрал wg-интерфейс. В захвате появились echo reply к адресу клиента, обратный forward-счётчик начал расти, а реальный клиент получил интернет через удалённый egress.

Что из этого стоит запомнить

Свежий WireGuard handshake доказывает только работоспособность транспорта. OSPF Full доказывает соседство и обмен маршрутами между роутерами. Masquerade доказывает, что пакет можно выпустить наружу. Ни один из этих фактов не гарантирует, что Linux выберет правильную таблицу для ответного трафика после обратного NAT.

Для таких схем полезнее не перебирать настройки вслепую, а строить короткую цепочку доказательств: вход в wg, выход из LAN, возврат на LAN, решение route lookup, возврат в wg. Как только каждый переход подтверждён захватом или счётчиком, «мистическая проблема туннеля» обычно превращается в одно конкретное правило.

Больше технических разборов публикую на сайте.

Рассмотрим три «ключевых» новых фишек от Apple. Это, конечно, графический интерфейс, смартфон и МР3-плейер.

В 1979 году Джобс прикатил в исследовательский центр Xerox PARC в Кремниевой долине. Руководители Xerox искали себе инвесторов. Потому разрешили инженерам от Apple посетить их центр. Там Джобс и увидел мышь на проводе, а потом еще иконки и окна на экране компьютера. Отчего пришел в полный восторг. Надо сказать,  что в Apple уже над этим работали. А Джобс обрадовался от того, что увидел все это в законченном виде, попутно для себя уяснив, что его фирма движется правильным курсом. Но факт остается фактом, графический интерфейс первым появился у Xerox.

Первый iPhon появился в 2007 году. Но  Apple не изобретала смартфон. Он появился еще 15-тью годами раньше. То был IBM Simon Personal Communicator. У устройства имелся сенсорный экран и стилус. С гаджета можно было звонить, отправлять почту и факс. А помимо этого, в нем были блокнот, календарь и адресная книга.

IBM Simon успешно расходился за $899 за штуку и преодолел порог в 50 тысяч единиц реализованного товара. Его брали бизнесмены и успешные дельцы.

Так что, первый смартфон – не детище Джобса, как многие считают. В Apple изобрели способ, как сделать смартфон удобным. Чтоб в него было комфортно тыкать пальцем. Причем любой толщины, простите за подробность. От толстого мужского до утонченного, с красивым маникюром, женского. Без всяких там стилусов. Смартфон от Apple соединил в себе элегантность и простоту использования с эффективностью программного софта. А этого не удавалось сделать ни IBM, ни Nokia с Microsoft.

Первый iPod в Apple «родился» в 2001 году. Первый в мире МР3-плейер изобрели корейцы в марте 1998 года. Его выпустила фирма Saehan. Интересно, слышал ли кто-то из ныне живущих о Saehan, в отличие от Apple?

Вообще саму идею цифрового плейер запатентовал один британец еще в 1979 году. Его звали Крейн Креймер. Опять-таки, кому теперь известно это имя, в отличие от Джобса, о котором знают даже дворовые собаки в России.

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

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

И в последнем Apple действительно гений. Ибо, иногда важнее не изобрести велосипед, а сделать его так, чтобы на нем было удобно сидеть и ездить.

Если вам удобно читать тоже самое (и даже больше!) в Телеграм, то приглашаю по ссылке на свой канал "ТехноДрама"

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

Cloudflare OS объединяет три основных компонента. Первый — рабочее пространство для взаимодействия с AI-агентами. В нём можно создавать приложения с помощью искусственного интеллекта, запускать их в изолированном окружении и решать поставленные задачи. Второй — инструментарий безопасного доступа. Gatekeeper-ы выступают посредниками между агентами, приложениями и внешними сервисами, включая GitHub, Slack, Google Drive, Jira и базы данных. Третий — платформа для создания, распространения, модификации и обмена персональными приложениями в форме gadget-ов.