3vi1_0n3

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

При декларативном подходе (CSS) мы говорим браузеру, что именно сделать, а он уже сам решит, как именно сделать это оптимально для себя и для устройства, на котором он работает. При императивном подходе (JS) мы контролируем каждый шаг и не даём свободы, браузер вынужден делать то, что автор скрипта скажет, даже если ту же самую задачу он может решить лучше и оптимальнее него.

Для первого - и в винде, и в линуксе для этого достаточно прописать путь к папке с исполняемым файлом в PATH - все терминалы (наверное все) именно там ищут "команды" (а точнее команда это и есть бинарь).

я профан в части серверов

Вот тут надо задуматься об услугах профессионала. Вы как никак пол ляма хотите на это потратить.

#!/bin/bash
select choice in "Текущий пользователь" "Данные о каталоге" "Запущенные процессы" "Выход"
do
  echo "$choice"
  case "$REPLY" in
    1) echo $(users);;
    2) ls;;
    3) ps;;
    4) break;;
  esac
done

Tar и gzip это очень старые утилиты. Им по 30-40 лет. И создавались они в те времена когда симметричное шифрование еще не было так развито.

Но архивчик можно после упаковки зашифровать другими утилитами например openssl.

openssl enc -in file.txt -out encypted_file.txt -e -aes256

Я так делал когда шифровал бекапы oracle dbms.

Если переписать чуть лучше скрипт - то можно объединить операции tar->gzip->openssl в один пайплайн
без воздания промежуточных файлов.

mysqldump -u $USER -p$PASS --ignore-table=myBase.log_chat --ignore-table=myBase.log_main --routines $DB > $BACKUP_DIR/mysql.sql
+ tar -czvf $ARCHIVE $BACKUP_DIR

Странное применение targzip в данном случае. совершенно бессмысленное.
Юзай просто zip, у него есть -e (encrypt) опция, но там слабенькая защита. уж проще openssl, как указали в другом ответе.

Чтоже касается tar. Весь смысл тар и gzip в том, что они умеют работать с потоком, а не файлом. Поэтому то, что вы сперва сохраняете в файл, а потом отдельно еще в tar/gz - бессмысленная работа, которая ничего не дает. Вдобавок и сам тар там не нужен, у вас же один файл.
Поэтому можно сделать так:

mysqldump -u $USER -p$PASS --ignore-table=myBase.log_chat --ignore-table=myBase.log_main --routines $DB | gzip > $BACKUP_DIR/mysql.gz

и потом шифровать файл чем угодно.
Или сразу:

mysqldump -u $USER -p$PASS --ignore-table=myBase.log_chat --ignore-table=myBase.log_main --routines $DB | gzip | openssl enc -aes-256-cbc -out encrypted $BACKUP_DIR/mysql.gz.encrypted

Пароль или руками или перенаправить

mysqldump -u $USER -p$PASS --ignore-table=myBase.log_chat --ignore-table=myBase.log_main --routines $DB | gzip | openssl enc -aes-256-cbc -out encrypted $BACKUP_DIR/mysql.gz.encrypted<<<"mysecretpassword"

Все сильно зависит от специфики вашего проекта, но по своему опыту могу сказать, что ФП хранилища в проекте с бизнес-логикой - зачастую хуже, чем ООП варианты.
В своих проектах обычно использую стек из Mobx + tsyringe(DI). С недавних пор добавил в эту схему React-Query. Иногда бывает полезно использовать MST, если ваша бизнес логика требует каких-то сложных моделей данных с собственной логикой, а так же сложной связи между ними. В частности, MST дает немного больше возможностей для проектирования моделей данных, нежели обычные классы с Mobx.
Поясню за ответственности:
1. Mobx - отвечает именно за бизнес-логику frontend приложения. Не надо туда пихать геттеры данных с бэкенда, которые нужно просто визуализировать, для это есть React-Query. Поскольку Mobx базируется в первую очередь на классах, для работы с ним мы можем применять ООП и соответствующие паттерны, выстраивая интересно логику из хранилищ и сервисов прямо на frontend. Для лучшего понимания как это правильно варить, рекомендую глянуть на backend.
2. React-Query - у них на сайте прекрасно описано, зачем они нужны, и этот инструмент в любом случае призван дополнять типичные хранилища состояний, будь то хоть Mobx, хоть Redux, хоть еще что-либо, рекомендую почитать. Отличный инструмент для работы с состоянием приложение в случае тех данных, которые просто нужно взять с бэка и отобразить.
3. Tsyringe - для меня проверенный и неплохой инструмент для работы с DI на фронте. Это гораздо лучше, чем пробрасывать хранилища внутрь других хранилищ через конструкторы или через глобальные переменные. Аналогично с подключением в эту схему сервисов. Сразу скажу, что есть риск запутаться в конфигурациях сборщика, если используете CRA, ибо и Mobx, и Tsyringe используют в своей основе декораторы, а babel их переваривает с переменным успехом, но если разобраться, настроить можно)

Опять таки, адепты Redux и ФП могут сказать, что я просто не умею готовить Redux. Действительно, не умею. Несколько раз пытался трогать Redux, но он не нравился ни до того, как узнал про Mobx, ни после. Верю, что разрабатывать на нем можно. Но и ухо можно чесать левой рукой через затылок. Чтобы Redux был производительным и эффективным, нужно понимать как устроены данные и как работает его реактивность. Он может неплохо подойти для менеджмента состояния каких-то простых моделей данных, например, форм. Но зачем нам центральное хранилище для форм?
Mobx в этом плане сильно проще и при хорошей архитектуре проекта и самого приложения, джуниоры редко могут там что-то вытворить своеобразное, да и производительность там поломать куда сложнее. В общем, Mobx банально удобнее и проще, но при этом не только не ограничивает разработчиков в возможности создавать сложные и элегантные решения, а только помогает в этом.

Вот такие мысли, надеюсь поможет)