vreitech

Как в Linux создать swap-файл с динамическим размером?

Никак.

Более того, это не нужно, поскольку надо пользоваться разделом, а не файлом (в раздел пишется напрямую, а в файл - поверх ФС, что менее эффективно).

Фронт развился в какую-то неправильную сторону, это правда
Вкатиться на фронт очень сложно, это тоже правда. Причём, необоснованно сложно.

Я бы выделил два пути, как можно въехать во всё это:
1. Создать приложение на Vue или React по туториалам, затем разобраться, как и зачем оно всё
2. Разобраться как и зачем оно всё (aka Vanilla JS), потом заняться реактами

Имхо, вариант №2 предпочтителен и более прост, потому что на варианте №1 есть огромный шанс застрять, никогда не разобравшись, как оно работает а при любых нешаблонных ошибках поднимать лапки.

Что здесь нужно понимать:
1. Есть разные версии ES (ecmascript), они все обратносовместимые. Программист может писать на любой версии, какая ему нравится. Обычно берут последнюю стабильную

2. Для проекта обычно есть две версии ES: та, на которой пишут программисты и та, которая исполняется в браузере или в ноде (об этом позже). Например, программист пишет на ES8, а код транслируется на ES5. Это позволяет использовать последние предсмертные хрипы писки моды JS при этом запуская всё на древнейшем говне вроде IE11. Перегонкой кода из JS/TS одной версии в JS другой версии занимается транспилятор: babel / esbuild / swc

3. Новые версии JS содержат расширения стандартной библиотеки, которых нет в старых браузерах (например Array.from, Object.entries и т.п.). Эти дырки затыкают полифиллы, они же shims. Самая популярная дырозатыкательная машинка — corejs

4. Весь код очевидно не пишется в одном файле и может быть написан на TypeScript (он же TS), JSX/TSX (реактовый синтаксис). Всё это нужно собрать в один или несколько файлов, то есть скомпоновать. Этим занимается bundler: часть webpack / esbuild / spark / etc.

5. Этот же парень отвечает за то, чтобы та тысяча библиотек, что лежит в node_modules, попала в итоговый условный main.js, но не целиком, а только то, что используется. Последнее называется tree shaking (типа навозную кучу node_modules потрясли как дерево, что упало — то не нужно)

6. (то самое "позже) Код может исполняться не только в браузере пользователя, но и на сервере без браузера вообще. Это нужно для SSR aka Server Side Rendering. SSR — это такой глобальный вонючий костыль для SEO. Дело в том, что стандартные SPA приложения содержат один DOM элемент, куда цепляется всё остальное приложение вроде реакта или вью, которое уже содержит всю вёрстку прямо в JS. Но не все поисковики согласны с таким подходом и некоторые (не будем показывать пальцем на яндекс) не умеют выполнять JS и индексируют только тот самый единственный DOM элемент, который существует на этапе отдачи страницы в браузер. Это уже потом к нему JS движком дорисовывается весь остальной сайт. Соответственно, сайт индексируется от слова "никак", а некоторым это важно. Например, когда SPA — это не админка. Для этого есть два выхода: страницы, важные для SEO, рендерить чем-то не-реактовым или сделать SSR — делать за яндекс работу на сервере (на ноде), представляя в уме, что у нас есть DOM и браузер (на самом деле нет), на выходе получать начальное состояние HTML, отдавать его клиенту (браузеру или поисковому роботу), а JS'ом её т.н. "гидрировать", иными словами — оживлять.

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

Начать советую с parceljs, который сильно проще в освоении, чем webpack. И на написании кода максимально без библиотек.

Вариант раз:
pgcli на питоне: https://github.com/dbcli/pgcli
Вариант два:
dnf install postgresql

Есть три пакета:
postgresql-libs - с базовыми библиотеками
postgresql - с psql
postgresql-server - непосредственно с СУБД postgresql

Нет, не проблема компиляции с Pyinstaller.

Самый простой способ - использовать perl. У него есть специальные ключи, которые автоматизируют выполнение из командной строки, цикл и печать в конце цикла. В результате команде можно передать просто регулярку или сделать простой однострочник, применяемый к каждой строке файла.

Ключ -e заставляет считать первый аргумент кодом, а не именем файла.
Ключ -n оборачивает этот код в цикл while(<>) { ... }
Ключ -p добавляет в конец print.

В результате команда perl -pne 's/foo/bar/' превращается в аналог скрипта такого содержания:

while(<>) {
  s/foo/bar/;
  print;
}

Конечно, как нетрудно догадаться, такой вызов аналогичен вызову sed s/foo/bar/ Таким образом, perl можно использовать почти как sed или awk, только с более богатыми регулярными выражениями и более широкими возможностями программирования.

Например:

some_command|perl -pne 's/foo/bar/g; s/lorem (\d+)/\1 ipsum/g' > output.txt
perl -ne '/([_\w]+)\s*=\s*"(.+)"/ && print "key $1 value $2\n"' /etc/environment

Это поддомен, а не префикс.
Или домен третьего уровня.
Ничего он не означает, так же как и m.

Могу ответить с точки зрения фрилансера:

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

Вот несколько советов, которые помогут улучшить «возвращаемость» фрилансеров:

• Чаще всего фрилансер готов делать работу сразу (особенно когда работает с вами первый раз), он показывает рвение и очень быстро всё делает. С вашей стороны ожидается, что вы можете оплатить работу мгновенно после того, как всё сделано и проверено как фрилансером так и вами. Если вы скажете фрилансеру, что вам нужно некоторое время, чтобы дойти до банкомата и пополнить счёт, потому что прямо сейчас не можете заплатить, это очень сильно испортит впечатление, и с большой вероятностью человек не покажет виду, спокойно без психов подождёт, когда вы ему заплатите, но в следующий раз работать с вами больше не будет. Фрилансер готов работать сразу, значит и вы должны быть готовы платить сразу.
  
• Если у вас низкая техническая подготовка, и фрилансеру приходится кроме самого кода очень много общаться с вами на тему, что именно нужно делать, желание работать дальше тоже пропадает. Чем меньше требуется обсуждений и созвонов в мессенджере, тем больше веротность, что фрилансер и дальше будет с вами работать. Фрилансеры обычно не считают переписку частью оплачиваемой работы и, соответственно, чем больше времени будет занимать переписка, тем меньше будет желание продолжать работу. Фрилансер обычно хочет сразу делать работу и не отвлекаться на всякую бесплатную болтологию.
  
• Если фрилансеру нужно заниматься в дополнение администрированием вашего сервера, а это заранее не обговаривалось, это тоже может испортить впечатление. Часто заказчики пишут, что им нужно поправить менюшку на сайте, а это в итоге превращается в правку менюшки, а потом залитие кода на сайт, настройка и перезапуск сервера и ещё какие-то подобные работы, которых в задании не было вообще. И, скорее всего, вы считаете само собой разумеющимся, что фрилансер должен уметь это делать, и думаете, что это нормальная практика, если он в дополнение к кодингу будет делать ещё и это. Дополнительно, если эти моменты ещё и не оплачиваются, шансы, что люди захотят с вами работать и дальше, снижаются ещё сильнее.
  
• Некоторые заказчики любят показывать свой авторитет. Запомните, что для фрилансера вы не начальник, а равноправный партнёр, и он ждёт от вас соответствующего уровня общения. Если вы строите из себя начальника, люди будут придумывать любые отмазки, но повторно работать не станут.
  

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

Добавьте ключ --single-transaction

mysqldump -u root -p basename --single-transaction > path/to/file.sql

Его написал мой коллега https://github.com/kamranahmedse/roadmap.sh/pull/196 Алексей Лесовский после сбора фидбека со всей нашей команды DBA. Так что вряд ли раскритикую год спустя.

"конца" у roadmap нет. troubleshooting и optimization бесконечны. А уж тем более необъятна hackers тематика.

Если заходить со стороны разработки - создайте маленькую базу неважно какой тематики (да хоть q&a сервиса), заполните сгенерированными данными гигабайт на 10-100 и заставьте это шевелиться за вменяемое время под синтетической нагрузкой (хоть pgbench). А потом начните менять схему данных, не останавливая нагрузку. А потом восстановить базу на состояние до миграции из бекапа.

Это Вам СЕО-специалисты такое сказали? Не получится так никак, поскольку главная - она же "/" всегда так запрашивается. Вот как в HTTP запросе "GET /" - убрать "/" ?

а что. в server name уже можно протокол/схему писать?

nginx.org/ru/docs/http/server_names.html

или это такая регулярка? ))