Saboteur

Консоль линукса и команду grep. Там много аргументов и возможностей.
Команда sed - это фактически консольный потоковый текстовый редактор. Очень мощный, но сложный в понимании. Проще освоить питон и пользоваться для ваших целей вот такими однострочниками:

$ man py | py 're.compile("\w{10,}").findall(sys.stdin.read())'
completion
expression
DESCRIPTION
expression
interpreter
compatible
expression
expression
arithmetic
automatically
distribution

Что тут происходит:
Берём справку по консольной тулзе pythonpy, конвейером передаём в эту утилиту, которая выполнит кусочек питоновского кода. Код читает всё, что приходит на вход и находит все слова длинной 10 и более символов.

Да, они заключают договор с каждый издательством. И условия договора индивидуальны. Конкурировать будет очень тяжело, ведь вы не сможете обеспечить издательству такие объёмы продаж, а потому не сможете заключить на столько же выгодный договор, как Литрес. Кроме того, вам понадобятся серьёзные вложения в организацию DRM, это не просто сайт со скачкой файлов запустить.

Вряд ли из-за 15 строк кода кто-то будет писать настолько уникальный функционал

// устанавливаем роль и дату начала тестового периода
function set_user_test_period() {

	$current_date = date( 'd-m-Y H:i:s' );

	// пишем в мету юзера текущее время
	add_user_meta( $user_id, '_test_period_start_date', $current_date, true );

	$user = new WP_User( $user_id );

	// добавляем роль участника
	$user->add_role( 'contributor' );

}


// проверка завершения тестового периода
function check_user_test_period() {

	$current_date = date( 'd-m-Y H:i:s' );
	$user_id = get_current_user_id();

	$test_period_start_date = get_user_meta( $user_id, '_test_period_start_date', true );

	$user = new WP_User( $user_id );

	// проверяем, что текущая дата больше тестового периода
	if ( strtotime( $current_date ) > strtotime( $test_period_start_date . ' + 7 days' ) ) {
		// убираем роль участника
		$user->remove_role( 'contributor' );
	}

}

Писал без тестов, может что-то не работать и логику нужно доработать по необходимости

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

потому что само-подписанный сертификат твой броузер не знает. попробуй использовать let's encrypt, если это сервер, который смотрит наружу в интернет, или добавь сертификат в список доверенных, если это только сервис локальной сети

Обратную зону настроили для адреса сервера?
А вообще, https://www.mail-tester.com/ и проч в помощь

Любой. Ну выжмете вы 50-150 мб озу. а потом придёт браузер и выжрет 850.
самое прожорливое не ОС, а современные сайты.
linux тут не спасёт.
если надо экономить озу, то ищите нетребовательные сайты, а не дистрибутив.

при чем тут termux? проверяйте правильно ли указаны репозитории у Вас. там же это написано

Никакие "пустые строки" в БД не добавляют. Это не тетрадка в клеточку.
Она работает по-другому.
Строки добавляют сразу заполненные, когда нужно.

Важно понимать следующее: нет никакой ложки

С точки зрения Линукса, данные, которые вы якобы пишете на диск - это страницы в памяти, которые помечены как неанонимные (это значит, что на диске есть файл, который с ними связан), и грязные (а это значит, что эти страницы надо сбросить на диск).

Причем момент, когда произойдет сброс, зависит от кучи факторов - программист на это может влиять таким образом:

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

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

После сбрасывания страниц на диск, ОС помечает их как чистые. Это значит, что их можно занять под что-то другое. Можете запустить htop и посмотреть на желтую полоску - это как раз те самые страницы кэша, и их может быть очень много.

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

А теперь важный вопрос - как же понять, остаются ли данные в кэше после записи. Да легко.

-очистите кэш sync; echo 1 > /proc/sys/vm/drop_caches
-посмотрите, что желтая часть на полоске памяти в htop исчезла
-запустите DD, запишите на диск гигабайт. (dd if=/dev/urandom of=test.raw bs=8M count=128 status=progress)
-посмотрите, что у вас нарисовался желтый гигабайт
-можете потом считать этот файл и увидеть офигительную скорость - выше гигабайта в секунду (у меня получается 6, что очевидно говорит о том, что чтение происходило из RAM). Последнее лучше делать, если писали на HDD - потому что хороший SSD может выдать столько же

Объективно, этот тест показывает, что ДА, записанные данные остаются болтаться в памяти.

Но при этом, момент, когда эти данные оттуда уйдут, зависит от множества факторов (скажем, если памяти - в обрез, PageCache пойдет под нож в первую очередь). Так что может оказаться полезным использовать другие стратегии - например, mmap