Vlad Ivanov, можешь посмотреть чат https://t.me/WeArchivingInternet, там как раз в последнее время много флуда было про способы кодирования видео, с примерами и обсуждениями настроек.
Дмитрий, проблема не в том, чтобы софт был опенсурсным или проприетарным, а в том, для какой задачи какое решение подходит в конкретной ситуации.
И некоторые задачи опенсурсные решения закрывают очень даже хорошо. А некоторые - нет. В том числе это может зависеть и от размера конторы, и от объёма задач, и от объёмов трафика/rps. А ещё от наличия специалостов и их навыков, их загруженности, наличия у них дорогих коммерческих сертификатов по работе с решениями специальной формы.
Я имел дело с админами клиентов, у которых супер-пупер ngfw, в котором "ну совершенно точно разрешено", а при этом выяснить, почему не работает, они неделю не могут, потому что никаких внятных средств отладки и сколько-нибудь адекватных логов там нет. Ну, точнее, там что-то есть, но вот как пить дать в данной конкретной проблеме ничё подходящего, чтобы позволило разобраться, найти не могут. А в опенсурсных решениях прозрачная структура решения, так что можно тот же tcpdump запустить, если уж совсем ничего не удаётся увидеть.
В Multipoint Server можно сделать постоянный доступ, без переключения. В Linux подобные штуки вообще сто лет назад делали. Запускаем 3 X-сервера на разные видеокарты и разведённые на разные клавомыши...
В данном примере делается один запрос, у которого в параметрах перечислены все 20 страниц. Естественно, результат будет плохой, ведь надо было сделать 20 запросов.
Можно сделать [requests.get(...) for n in range(20)]. но получится список response. Но такие вещи обычно удобнее в цикле делать. Чтобы можно было сразу ответ обработать, ошибки отловить, возможно повторно запросы выполнить (например, по 5 попыток до полного отказа). В list coprehesion уже не засунешь дополнительной логики.
Кроме того, в таких API обычно неизвестно заранее число страниц, и необходимость следующей страницы определяется по данным предыдущей.
My_Second_Nickname,
1. Снять образ системы (бэкап).
2. Накатить новую версию Debian
3. Постараться добиться работоспособности астериска
4. Повторить сначала в случае удачи.
В итоге, если повезёт, получится новая версия Debian с сохранением старого астериска.
Но лучше превентивно начинать разбираться с бардаком в астериске. Документировать, разбирать конфиг на части. Собрать тестовый стенд на новой версии и постепенно приделывать к нему старый функционал.
Иначе можно когда-нибудь оказаться в ситуации, в которой всё помрёт и быстро уже не починишь. Или когда потребуется что-то, что нужно срочно, а в старом астериске уже не сделаешь.
Плюс хром жрёт память даже на полсотни вкладок сильно неадекватнее, чем FF.
Плюс рабочий чат (Rocket.Chat), который худшее электронное поделие из всех виденных мной электронных поделий - он иногда гиг-другой сжирает н пустом месте.
Как результат, иногда у меня сильно вытекала память в своп и оживала либо по OOM-киллеру, или по моему ручному отстрелу самого опухшего процесса из консоли.
Ещё у меня подозрение, что в хроме в каких-то версиях расширения иногда начинали выжирать много памяти и этому помогало их выключить-включить либо найти и отстрелить слишком пухлые процессы.
В любом случае, 8 Гб точно не советую и в это поддерживаю остальных ораторов.
Работал на 16 Гб (правда, Linux) и постоянно испытывал проблемы с нехваткой памяти. Два браузера с кучей вкладок (и Auto Tab Discard, без которого было бы совсем туго) и ещё несколько приложений, которые тоже иногда хотят памяти (Thunderbird, DBeaver, рабочий чат на электроне...).
Когда рабочий ноут сдох, попросил в новый 32 Гб памяти, а мне выдали сразу 40 Гб.
8 Гб - это в наше время для офисной машинки, на которой в конце рабочего дня браузер со всеми 5-10 вкладками полностью закрывается. Для профессионального разработчика - тем более веб-разработчика - этого слишком мало.
Тем более что аппетиты браузеров, разработчиков софта и сайтоделов растут с каждым годом. Ещё 10 лет назад куча народу обходилась 2 Гб памяти, а 15 лет назад в ходу были "нетбуки" (т.е. по своей идеологии нацеленные на браузер маленькие ноуты) с 512 Мб.
