pfg21

Контейнеры.

Proxmox + LXC в помощь

-r, --reverse
reverse order while sorting

-R, --recursive
list subdirectories recursively

Linux с которым ни разу не сталкивался за 20 лет

А Вы точно из IT? :)

Файловый сервер - это скорее всего samba
Почитать стоит также о правах на файлы, о iptables, о дистрах и разнице между ними (как минимум deb-based и rpm-based).
Почитать что такое SSH и доступ к серверу по ключам. Скачать и пощупать какой-нить putty.
Команды нужные гуглятся за секунды, но какойнить "Карманный справочник по командам Linux" можно и почитать.

Принцип KISS не означает что надо использовать самые примитивные инструменты.
Он означает, что не надо переусложнять систему без нужды.
Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

Для того, чтобы упростить управление системой, её надо усложнить.
Этот принцип относится к любой области человеческой деятельности, от постройки ракет до управления государствами.
Чем сложнее система, тем больше накладные расходы на ее управление. Хоумпейдж с котиками можно и нужно делать примитивными средствами. В большом проекте надо сразу закладываться на будущую расширяемость. То есть, заранее делить ответственность между "леерами".

И кстати. Код, в котором "всё друг на друге завязано" - это очень плохой код. Собственно, предназначение всех этих "лееров, провайдеров и репозиториев" как раз в том, чтобы компоненты были как можно более независимы друг от друга.

Все зависит от конечной задачи и нюансов в ней, вариантов в общем масса:

1) Использовать готовые протоколы типа ftp\scp\ssh\etc и их реализации клиент-сервер. В такой ситуации придется мириться с их проблемами\ограничениями\сложностями.
2) Пойти тупым путем, установить соединение, открыть стрим файла и пихать его в сокет, на другой стороне также открыть стрим и пихать все пришедшее на сокет в него. Тут уже сами себе буратино и можете извращаться и решать проблемы сами.
3) Пойти правильным путем и написать сначало тз для себя в котором точно определитесь что и как необходимо, необходимые меры надежности передачи и все возможные проблемы и методы их решений.
Т.е. образно говоря можно взять принципы передачи пакетов tcp\ip за основу:
1) Перед началом передачи файла передать crc файла клиенту, клиент посмотрел что такого нет и отвечает что ждет приема. Можно расширить и к примеру ответить что файл есть но изменился а значит надо передать только изменные блоки.
2) Сервер получив согласие клиента разбивает файл на чанки(некоторый заданный размер блоков)
3) Сервер отправляет crc клиенту и блок, клиент получает crc и получает блок затем сверяет его с crc и отвечает что все ок, сервер делает также со всеми оставшимеся блоками, если сервер не получил ок от клиента то отправить блок снова. Если расширять то можно сделать новый ответ серверу что такой crc для такого блока есть и давай следующий.
N) дорабатываешь все это до желаемого результата, к примеру добавляешь сжатие блоков, нумеруешь их чтобы не слать последовательно а была возможность асинхронной передачи, добавляешь шифрование и т.д.

usermod -s '/usr/bin/ssh 192.168.0.2' vasya

echo "ssh 192.168.0.2" >> /home/vasya/.bashrc

1. написать сервер который будет знать список активных устройст и расказывать об этом клиентам.
2. UDP broadcast
3. что-то ещё - не как у всех. :)

Это просто не моноширный шрифт.