3vi1_0n3

Можно рассмотреть вариант, который работал десятки лет назад как дефолтный? Тот, где папка /usr монтировалась по сети (NFS), программы лежали в /usr/bin. Устанавливается всё на сервере, файлы доступны при этом на всех машинах, выполняются на клиентах локально, настройки пользователя хранятся в домашней директории пользователя.

Определить время на тестирование нового продукта/сайта более или менее точно нельзя. Это в определенных рамках возможно только для продуктов, которые вы уже тестировали, из-за высокого фактор неопределенности качества предоставленного сайта, которое, к тому же, может быть неравномерным.
При тестировании продукта, который вы знаете (или хотя бы поверхностно познакомились), вы как-то можете использовать исторические данные, чтобы с определенной долей вероятности экстраполировать потенциальное количество багов и сколько это может занять.
В описанном случае у вас нет достаточно информации, чтобы до начала тестирования предположить, сколько времени это займет. Тем более, что его до этого никто не тестировал, судя по всему. Есть вариант попытаться угадать поточнее, если у вас есть опыт с похожими сайтами, но там тоже будет погрешность. Их всё-таки разные люди делают.
Поэтому в таком варианте, как вы описали (новый сайт, который вы в глаза не видели), можно сказать, мол, для более точной оценки с учетом всех факторов надо протестировать 5% (лучше 10%) страниц, засечь время, которое заняло, и на основе этого предполагать, сколько займет полное тестирование с учетом среднего количества багов на страницу или что-то вроде этого. Пусть оплачивают эти 5-10%, а там уже, если не хотят продолжать, то и ничего не поделаешь.

Если вам надо писать на баше, то надо делать ровно то, что надо, и не более. Баш достаточно буквальный язык.

Первая часть:

#!/bin/bash

# Создаем шаблон конфига из скрипта (без использования массива)
cat > ./syslog-template <<"EOF"
/var/log/syslog
{
  rotate 10
  size 10M
  daily
  missingok
  copytruncate
  notifempty
  compress
  delaycompress
  sharedscripts
  postrotate
    invoke-rc.d syslog-ng reload > /dev/null
  endscript
}
EOF

# Удаляем секцию из файла
sudo sed -i '/\/var\/log\/syslog/,/}/d' /etc/logrotate.d/syslog-ng
# Добавляем секцию в файл
# Тут, возможно, надо будет " | sudo tee -a" вместо пайпа
cat ./syslog-template >> /etc/logrotate.d/syslog-ng
# ^-- Вот эту команду можно совместить с первой, чтобы не создавать лишний файл

Вторая часть (не уверен, зачем она вообще нужна (так как изменения, внесенные первой частью, идемпотентны), но, раз вопрос так стоит, то пусть будет):

#!/bin/bash

# На момент вызова файл шаблона должен существовать
ORIGINAL=$(cat ./syslog-template) 
EXISTING=$(sed -rne '/\/var\/log\/syslog/,/}/p' /etc/logrotate.d/syslog-ng)
[[ "$ORIGINAL" == "$EXISTING" ]] && echo "файл настроен" || echo "файл не настроен"

Ошибка не имеет отношения ко всему этому коду.
Обновите хромдрайвер до версии, которая поддерживает вашу версию браузера.

Буду оригинален. Если основная задача - интернет-браузинг, то может что-то вроде ChromeOS Flex?
Вроде где-то видел, что туда уже завезли Linux окружение как во взрослом ChromeOS.
И сделано оно вроде на Дебиане.

Собирал свежие ядра пару лет под Дебиан, пока поддержку некоторого железа в пакетном не завезли через два релиза, потом перестал. Там очень много непонятного между пакетными ядрами и сборкой из исходников.
Несколько примеров:
1. По умолчанию куча новых модулей (не входящих в старые версии) включена. Если использовать конфиг от старого ядра, новые модули может понадобиться отключать руками.
2. По умолчанию куча модулей для старого железа включена.
3. Есть шанс, что определенные модули идут в разных пакетах и не входят в дженерик в дистрибутивных сборках, либо исключены совсем. Из сырцов вы получите всё, вообще всё, что есть в исходниках, либо в модулях, либо в основном ядре, если специально не отключать, в том числе кучу старых девайсов, которых у вас скорее всего нет, или платы видеозахвата, которые вам, например, не нужны.
4. Если хотите собрать ядро поменьше, придется внимательно читать информацию по железу и тратить реально дофига времени на то, чтобы оставить в монолитном куске только то, что нужно, включая все зависимости, остальное либо собирать модулями, либо отключать совсем.
5. Можно поотключать вообще всё и постепенно включать то, что имеет смысл. Грузиться нормально скорее всего сразу не будет, но по ошибкам обычно можно примерно понять куда копать.

Разобраться с этим списком быстро не будет. Можно взять конфиг из пакетного ядра, и начать копать от него, в любом случае это вопрос количества попыток, опыта и уровня понимания что там зачем. Scheduler, например. Есть возможность выбрать один из поддерживаемых, но надо знать, что это такое, и различия между ними. Где-то видел
статью про планировщики, возможно на хабре.

Я обычно собирал реально только то, что использовал, преемптивное ядро, плюс USB-устройства выборочно (клавы-мыши в монолит, то, что потенциально могу использовать - в модули), плюс поддержку в ядре файловых систем выборочно (одну, которая используется на корневом разделе, в монолит) и так далее. И после успешной загрузки проходил еще несколько раз и смотрел, что я могу еще отключить совсем, чтобы не собирать ненужное. Занимает обычно лютое количество времени, чтобы найти, прочитать и понять что там что, и довести до состояния "только необходимое плюс немного на перспективу". Собственно поэтому бросил этим страдать сразу как дистрибутивное ядро в пакетах проапдейтилось до нужной версии.

В плане как собирать, пакетом или через make - пакетом скорее всего удалится чище, руками не надо удалять ничего, и по размеру пакета можно оценить размер сборки сразу. Хотя это и так несложно, всё лежит в известных местах.

Руководства, которое объясняет, что надо, а что не надо, не видел никогда. Скорее всего потому, что всё очень быстро меняется, за полгода в ядро вливают кучу кода. Это было заметно даже во времена версий 2.4/2.6.
Поэтому make menuconfig и гуглить непонятное.

Тут уже много интересного написали. Штука только в том, что в вопросе недостаточно информации, что не позволяет эту задачу решить эффективно. Есть вопросы, на которые надо ответить, прежде чем приступать:

1. Где хранятся эти файлы, которые могут потенциально вырасти до таких размеров и сколько их?
Если они хранятся в одной директории, тогда смысла делать поиск по всей системе нет. На моем десктопе с 500К файлов поиск занимает примерно 9.5 секунд с полным сканированием дерева файловой системы. Если файлов потенциально пара сотен, и они все в одной директории или в поддереве директорий, время поиска можно сильно сократить. Я подозреваю, что find читает информацию о размере из inode'ов, поэтому количество файлов играет значительную роль.

2. Что это за файлы, надо ли их на самом деле мониторить?
Если это логи, к примеру, есть много способов этого не делать (ротация логов, централизованное хранение), если это образы дисков для виртуальных машин (LVM, или еще что), то find может быть не совсем верное решение, могут быть другие инструменты (получение данных из гипервизора, и так далее)

3. Можно ли сделать линки на директории, в которых хранятся файлы, в одну директорию и сканировать её вместо всей файловой системы?
Логично, что, если файлы хранятся где попало и их надо искать по всей системе, поиск будет занимать больше времени.

Про inotify там выше уже дали ссылку на мою статью 2016 года. Это на самом деле самый лучший вариант, если надо сразу знать об изменениях файлов, и самый удобный. Вот только он может вполне быть "из пушки по воробьям", если вам не надо прямо сразу узнавать о событиях файловой системы и обрабатывать их, а достаточно периодических проверок (с учетом вопросов выше).

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

Учитывая, что вы хотите это сделать через bash, я бы сначала посчитал, сколько подобных событий (увеличение размера файлов до 16+Тб) происходит и попробовал оптимизировать поиск таких файлов за счет отсекания ненужного поиска (специфическая директория, фильтрация по типу файлов, имени и прочее).

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

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

P.S. updatedb делает то же самое примерно, что и find, поэтому не надо его вызывать каждый раз перед использованием locate

Хехе. Я думаю препод большой шутник, если так завуалировал DBLSPACE, который можно загрузить в верхнюю память в том числе

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

Если вам прям очень надо именно заменять сам скрипт по условию, то лучше это делать так:
1. Вызываем /etc/init.d/medteco.sh
2. Скрипт /etc/init.d/medteco.sh проверяет наличие скрипта на флэшке
3. Скрипт /etc/init.d/medteco.sh проверяет целостность скрипта на флэшке
4. Если скрипт существует и проверка целостности проходит, копируем на диск под другим именем, проверяем целостность еще раз. Контрольную сумму можно заранее посчитать тем же md5 и положить в файл рядом с новым скриптом.
5. Если шаг 4 успешен, удаляем/переименовываем старый скрипт (тот, который не /etc/init.d/medteco.sh, а старая версия скрипта с флэшки), переименовываем новый скрипт в старый.
6. Безусловно выполняем/source'им тот самый скрипт, передавая ему параметры при необходимости. В этом случае у вас будет вызвана либо старая рабочая версия, либо новая рабочая версия.

Скрипт /etc/init.d/medteco.sh затронут не будет (и не должен), он будет нужен для обработки ошибок и т.д., чтобы контролировать процесс независимо от его результата. Если прямо очень надо, чтобы старая версия не запускалась, бросаем ошибку и прерываем выполнение скрипта.

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

На баше как-то так (минимум внешних команд, от cat можно избавиться, если использовать exec):

#!/bin/bash

octets=({0..1}{0..1}{0..1}{0..1}{0..1}{0..1}{0..1}{0..1})

addrtobin(){
    for digit in ${1//./ }; do echo -n ${octets[digit]}; done
}

# Просто пример для списков адресов и сетей.
# Лучше используйте exec N<>filename.txt + read -u N
ips=$(cat ips.txt)
nets=$(cat nets.txt)

for ip in $ips
do
    out=1
    bin_ip=$(addrtobin $ip)
    for net in $nets
    do
        bin_net=$(addrtobin ${net%%/*})
        net_mask=${net#*/}
        if [ "${bin_ip:1:$net_mask}" == "${bin_net:1:$net_mask}" ]
        then
            out=0
            break # Чтобы не проходить до конца списка сетей, если адрес уже найден
        fi
    done
    [ $out -eq 1 ] && echo $ip
done

К сожалению, придется делать двойной цикл. К счастью, можно не прогонять внутренний цикл до конца, если совпадение найдено, поэтому будет самую малость быстрее.

Попробуйте Process Explorer отсюда - https://learn.microsoft.com/en-au/sysinternals/dow...
Он вроде бы умеет приоритет на I/O.
Точнее он умеет в Background приоритет, что влияет в том числе на I/O

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

SELECT t1.sum_za_zakazy AS sum_za_zakazy,  t2 .......

FROM ( SELECT COALESCE (sum(v2.meta_value),0) AS sum_za_zakazy
       FROM wp_posts
       JOIN wp_postmeta v1 ON (wp_posts.ID = v1.post_id)
       JOIN wp_postmeta v3 ON (wp_posts.ID = v3.post_id)
       JOIN wp_postmeta v2 ON (wp_posts.ID = v2.post_id)
WHERE wp_posts.post_type='zakazy'
AND wp_posts.post_status='publish'
AND v1.meta_value = '%current_field|id_uchastnika%'
AND v3.meta_value
    BETWEEN '%current_field|data_1%' AND '%current_field|data_2%'
AND (
   (v1.meta_key = 'id_shvei_1'           AND v2.meta_key = 'summa_shvei_1'           AND v3.meta_key = 'shveia-1-data')
OR (v1.meta_key = 'id_shvei_2'           AND v2.meta_key = 'summa_shvei_2'           AND v3.meta_key = 'shveia-2-data')
OR (v1.meta_key = 'id_shvei_3'           AND v2.meta_key = 'summa_shvei_3'           AND v3.meta_key = 'shveia-3-data')
OR (v1.meta_key = 'id_razborshhika_1'    AND v2.meta_key = 'summa_razborshhika_1'    AND v3.meta_key = 'razborshchik-1-data')
OR (v1.meta_key = 'id_razborshhika_2'    AND v2.meta_key = 'summa_razborshhika_2'    AND v3.meta_key = 'razborshchik-2-data')
OR (v1.meta_key = 'id_sborshhika_1'      AND v2.meta_key = 'summa_sborshhika_1'      AND v3.meta_key = 'sborshchik-1-data')
OR (v1.meta_key = 'id_sborshhika_2'      AND v2.meta_key = 'summa_sborshhika_2'      AND v3.meta_key = 'sborshchik-2-data')
OR (v1.meta_key = 'id_sborshhika_3'      AND v2.meta_key = 'summa_sborshhika_3'      AND v3.meta_key = 'sborshchik-3-data')
OR (v1.meta_key = 'id_dostavki_v_czeh'   AND v2.meta_key = 'czena_dostavki_v_czeh'   AND v3.meta_key = 'data-zabora')
OR (v1.meta_key = 'id_dostavki_iz_czeha' AND v2.meta_key = 'czena_dostavki_iz_czeha' AND v3.meta_key = 'data-dostavki')
OR (v1.meta_key = 'id_menedzhera'        AND v2.meta_key = 'summa_menedzhera'        AND v3.meta_key = 'data-zakaza')
)) t1

CROSS JOIN( SELECT COALESCE (sum(v2.meta_value),0) AS ....... t2

Так хотя бы более понятно.
Все общие условия выносите в начало. Всё, что используется всегда, для всех комбинаций ключей.
Я поменял порядок джоинов (v2 и v3), на случай, если планировщик не додумается, в каком порядке фильтровать, хотя я не уверен, что это будет проблемой, но планировщики не всегда работают умно, иногда надо подсказывать. По дефолту JOIN в MySQL, если правильно помню, INNER, поэтому в теории можно подрезать набор данных слева таким образом.
Вот после этого попробуйте, сравните время запроса и результат с тем, что до, и потом используйте EXPLAIN <ваш запрос>. Есть вероятность, что внутренний SELECT выполняется для каждой записи.
На поля wp_posts.post_type и wp_posts.post_status можно будет потом (при необходимости) сделать индексы, если их еще нет (можно комбинированный).
На wp_postmeta.meta_key исходя из полученной картины можно будет сделать индекс, если его еще нет, как и на wp_postmeta.meta_value, хотя я бы ожидал, честно говоря, что они уже есть.
Просто так индексы создавать не надо, только при необходимости.

Можно попробовать atop. Он умеет собирать статистику, и ее потом можно просматривать. Ну, и в интерактивном режиме умеет. Должен быть в стандартных репозиториях.
Единственное надо будет задать интервал сбора метрик покороче, если хочется поймать краткие всплески.

Есть некоторая вероятность, что пакеты, которые работают с chromedriver, используют нативные бинарники, которые тянут сами (во время установки пакета, например). Не для всего эти бинарники есть под не-Интел архитектуры.
Например, локальный запуск chromedriver'а может не сработать, потому что нет chromedriver'а под архитектуру вашего телефона. Под нее в теории может быть chromium-driver (который делает ровно то же самое), но не факт, что он есть для termux в принципе. Для других linux-дистрибутивов он может быть скомпилирован майнтейнерами дистрибутива.
Тут может быть более одной проблемы, недостаточно информации, чтобы сказать точнее. А именно: что используется в скриптах в качестве эндпоинта для селениума, локальный URL или удаленный, какие именно пакеты ставятся для работы с Selenium, тянут ли они свой бинарь для вебдрайвера и так далее.

Посмотрите Ссылка удалена модератором. Selenium IDE. Похоже на то, что надо?

Вот так скачать все одной командой:

echo "" | openssl s_client -showcerts -connect d.codeartifact.eu-north-1.amazonaws.com:443 | sed -ne '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' > certs.txt

Если сертификат самого сервера не нужен, то можно его удалить из этого файла (certs.txt), но я, честно говоря, оставил бы, если вам надо проверять аутентичность соединения именно с этим доменом.