Александр Карабанов

В нём нет уязвимостей: дистрибутивы исправляют (бэкпортируют) их в текущей версии, не обновляя ПО до более новой. Так поступают все дистрибутивы с долгосрочной поддержкой.

Если вы хотите обновить версию, вам придётся скомпилировать её самостоятельно.

А какой тебе нужен?

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

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

Цена последней сделки (ticks) никаким боком не гарантирует что следующая сделка будет исполнена по этой же цене.

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

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

Все это потому, что существует понятие ликвидности торгов. Она не бесконечная (есть оговорки, смотрим к примеру dex на эфире - Synthetix).

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

Принцип следующий:

1. Делаете контейнер с фронтом-балансировщиком (nginx или что-то подобное).
   
2. Запускаете второй контейнер с бэком, содержащий новую версию.
   
3. Новый контейнер подключается к балансировщику. Тут дальше возможны варианты - балансировщик автоматически начинает переводить траффик на новую версию. Или в каком-то соотношении. Или только тестовый трафик. Или переключаете балансировщик на новый контейнер вручную. Или... (в общем вариантов тут много). Идея в том, чтобы перейти в целевое состояние - запросы обрабатывает новый бэкэнд. На этом этапе старая и новая версия бэкэнда должны уметь работать параллельно, то есть часть запросов может обрабатываться старой версией, часть новой, что налагает на новую версию требование сохранения обратной совместимости со старой версией (в частности это ограничивает возможные изменения структуры БД). В любой момент, если новая версия заработала как-то не так, можно "вертать всё взад", то есть опустить контейнер с новой версией и вернуть весь трафик на старую.
   
4. Убедившись что новая версия работает стабильно, переводите с балансировщика весь трафик на новую и опускаете контейнер со старой версией, оставляя контейнер с новой единственным.
   

Не очень понимаю что вы подразумеваете под контейнером с фронтендом, если это просто веб-сервер, который раздает SPA-приложение (HTML/CSS/JS), то в принципе аналогично.

Схема такого апгрейда не слишком проста в реализации, поэтому такой апгрейд (zero-downtime upgrade) применяется в энтерпрайзе, в котором никак нельзя допустить простоя в обслуживании. Поэтому смотрите сами - насколько те несколько секунд (максимум минут) простоя за которые запускается новый контейнер стоят этой возни. Если такой апгрейд действительно нужен, то советую вместо docker compose посмотреть в сторону kubernetes.

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

Да, так

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

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

Возможно, непонимание происходит оттого, что существует не один, а несколько векторов атаки на пароль.

1. Поиск хэша по "радужным таблицам" (rainbow tables): огромным базам данных, где собираются заранее посчитанные хэши для любых возможных строк.
   
2. Метод грубой силы (bruteforce): перебирать все комбинации символов и применять к ним хэширующую функцию до тех пор, пока она не вернёт искомый хэш.
   
3. Поиск по словарю. Похож на брутфорс, но перебор не всех возможных значений, а всего нескольких тысяч самых популярных паролей, типа "123", "password" и пр.
   

phpfaq.ru/tech/hashing

И только одного элемента недостаточно, а нужны все в комплексе:
- Хэширующая функция должна иметь большую вычислительную сложность, чтобы усложнить подбор перебором. по этой причине md5() не подходит
- Хэш должен быть посолен уникальной солью, чтобы нельзя было, затратив 1 раз кучу вычислительных усилий, заранее построить хэши для любых комбинаций символов. По этой причине фарш без соли - деньги на ветер.
- Пароль не должен быть слишком простым, иначе даже медленный перебор его раскроет. Этот момент тоже надо учитывать

Вместо браузера используй те инструменты, которые для этого предназначены.
Уже названный консольный curl вполне подходит для этого.
Если консоль для тебя не очень привычный инструмент - попробуй postman

Тут: https://www.gnu.org/software/coreutils/

Дело обстоит следующим образом.

Load AVG показывает суммарную загрузку по всем ядрам процессоров (или ядерным потокам). Другими словами - это суммарный показатель загрузки всей системы.

Но, в утилите top/htop можно посмотреть загрузку по каждому ядру (потоку ядра) в отдельности - нажмите кливишу 1, увидите загрузку каждого ядра в отдельности.

Возвращаясь к Load AVG:
- если у вас в системе 1 процессор, и AVG равно единице, то у вас система загружена полностью;
- если у вас в системе 16 процессоров, и AVG равно единице, то у вас система загружена на 1/16 часть;
- если у вас в системе 16 процессоров, и AVG равно 16, то у вас система загружена полностью;
- если у вас в системе 1 процессор, и AVG равно 16, то у вас система полностью перегружена, и я бы добавил 15 ядер.
Другими словами, что либо сказать только по значению AVG нечего, без знания о количестве ядер (ну как минимум).
В общем, как-то так...

$connection = ssh2_connect('www.example.ru', 22);
ssh2_auth_password($connection, 'username', 'password');

ssh2_scp_send($connection, '/local/filename', '/remote/filename', 0644);

Если вы используете $wpdb, то зачем mysqli_fetch_assoc-то, подсчёт результатов, цикл while и прочая ерунда?

<?php 
require_once($_SERVER['DOCUMENT_ROOT'].'/wp-load.php');
global $wpdb;
$results = $wpdb->get_results("SELECT * FROM stats_players ORDER BY logins LIMIT 10");
?>

<table class="gradienttable">
    <tr>
        <th>Позиція</th>
        <th>Гравець</th>      
        <th>Входів</th>
    </tr>
    

    <?php foreach ($results as $i=>$row) { ?>
        <tr>
            <td><?= $i+1 ?></td>
            <td><?= $row['name'] ?></td>       
            <td><?= $row['logins'] ?></td>
        </tr>
    <?php } ?>
</table>