Алексей Пьянов

Гента, слака, LFS

Правда, юзерфрендли их ну никак не назовешь :)

Не путай размер дистрибутива и размер установленной системы на диске

Дистрибутив на установочном livecd/liveusb диске это минимально рабочий (или специально подобранный для типового пользователя) набор пакетов, чтобы минимизировать запросы к серверам репозитариев мейнтейнера, а вот их размер почти у любого дистрибутива - десятки гигабайт.

Например одно время ubuntu server альтернативно можно было установить, загрузившись в примерно 100-200мб iso образ, с установщиком, который с удобным текстовым интерфейсом устанавливал абсолютно все пакеты по сети из репозитария..

Место, занимаемое установленной ОС зависит не от выбора мейнтейнера, а от выбора софта, который тебе нужен. Что бы ты не выбрал, пример - если тебе нужно ставить пакеты для разработки нейронных сетей (tensorflow) на nvidia gpu, то качать тебе минимум 5 гигабайт всего что с этим связано (а то и больше).

Единственный известный мне дистрибутив (с большим комунити), дающий наибольший контроль над устанавливаемыми компонентами - это gentoo. Он не спроста компилирует каждый пакет под пользовательские настройки, в нем с помощью тех же USE флагов определяются не только возможности но и зависимости, которые потянут за собой устанавливаемые пакеты.

К сожалению, юзерфрендли его не назовешь, так как поддержка обновлений своего конфига это достаточно тяжелый труд (хоть и предоставлена куча удобных инструментов), который если запустить на год другой, может сильно усложнить дальнейшее обновление системы, вплоть до ее полной переустановки (по крайней мере так было с 5-10 лет назад). Придется изучать и разбираться почти во всем, что ты используешь. С gentoo именно ты являешься мейнтейнером своего дистрибутива.

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

Купить роутер.
Воткнуть в него провайдерские хвосты.
Настроить NAT.

PROFIT!!

Любая база. MySQL справится на ура.

Выбирать базу данных по картинке - задача неблагодарная. В вашем случае я не вижу каких-то особых требований к базе, поэтому возьмите ту базу которую вы уже знаете. Если не знаете ни одной - возьмите MySQL (самая популярная база для WEB проектов)

- симка для аккаунта телеграмма куплена с рук (уже была верифицирована);
и все ваши пароли и прочее известны всем кто имел ранее доступ данной симке

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

Я бы замутил велосипед на ансибл.
настроить все sshd, чтобы ключи читались только из /etc/ssh/keys/%user/, чтобы никто себе руками ничего не ковырял. И все. Раз в сутки по всем машинам пробежался, обновился и готово

попробуйте. видимо криво скачалось

rm -rf /var/lib/apt/lists/partial/
rm -rf /var/lib/apt/archive/partial/

вариант1: прописать связь доменного имени и ip в hosts рабочей машины
вариант2 сложнее: поднять днс в локалке и настроить в нем эту связь.

Платный софт перебиранием /usr/bin искать бесполезно.
Например, IDE от JetBrains (как образец платного софта) - это тупо папка, которая может лежать где угодно, программа запускается лежащим в этой папке скриптом.
Может быть, имеет смысл искать не установленный софт, а - запускавшийся? Получая список файлов и папок в "хомяке" пользователя (в частности, ~/.config, ~/.local и т.п.), где уж платные-то программы непременно создадут свои записи.
Ну, и с Wine, конечно, отдельная песня...

Составить список популярных пакетных менеджеров и команд их вызова. Разные дистры используют разные менджеры (apt и yum встречаются чаще всего, ЕМНИП).
Для каждого менеджера попытаться получить список установленных пакетов. Также иметь ввиду, что данного менеджера может и не быть на данной машине.
Свести результаты в один список.

Например, для дистров, которые используют apt (Debian и его потомки), это либо apt-mark showmanual, либо apt list --installed | grep -v 'automatic' (чтобы исключить пакеты, которые были поставлены как зависимости для других). Но и там будут пакеты, поставленные при установке ОС.

Если хочется ну прямо супер детальный анализ... найти все файлы, помеченные как исполняемые. Потом узнать список установленных пакетов. Для каждого пакета узнать список установленных файлов. Исключить эти файлы из числа найденных. То, что останется, было установлено помимо менеджера пакетов и потому заслуживает более пристального внимания. Но сам понимаешь, это долго и жорко, ну и всё равно может не дать 100% покрытия. Грубо говоря, если некий файл script.sh не помечен как исполняемый, его всё равно можно запустить через bash script.sh.

Я думаю, стоит обращать внимание, если в списке установленных пакетов есть wine, mono или виртуальные машины. В остальном... вряд ли что-то найдётся.