Не сказал бы, возможно большинство просто не в курсе что можно лучше, лично я по той же причине не пользуюсь стримингами, лучше вообще не смотреть чем смотреть на кашицу из пикселей и градиентные квадраты в темных частях кадра...
Хотя в части причин я может и не прав, т.к. по моим наблюдениям даже на трекерах раздачи в 720р с шакальным качеством более популярные чем более качественные варианты.
А в части стриминга проблема не только в качестве, но и в том что даже с гигабитным подключением не всегда удаётся смотреть видео в 1080 без подгрузок и подвисаний, то ли CDN перегружены то ли каналы провайдеров, я уж молчу про мобильный интернет за пределами крупных городов...
Это конечно будет жрать батарею пользователя, но её не жалко, экран и так жрёт.
Вот вообще не факт, сам процесс может потреблять больше энергии но он может быть сильно короче за счёт чего общее потребление меньше. хотя в рамках задачи воспроизведения видео с фиксированной продолжительностью возможно экономии не будет. Хотя остаётся вопрос удобства, заикающееся на 15 секунд каждые 5 секунд видео, даст больше негатива чем чуть более быстрый разряд аккумулятора.
Ну тут на самом деле может быть несколько факторов:
Если это не коммерческий проект с солидным бюджетом на оборудование и монтаж, то оно вероятно изначально снималось на тапок и монитровалось на третьем пентиуме, хорошо если там будет x264 с не самым быстрым пресетом в 720р.
Как показано в статье видео может быть недостаточно популярным что бы гугл решил перекодировать его в более качественные кодеки, особенно в сочетании с его малым размером из-за пункта 1.
В последнее время гугл ввёл JS капчу и если её не решить он не отдаёт видео вообще или отдаёт только самые низкокачественные, yt-dlp не умеет из коробки их решать, нужно ставить JS и плагин для yt-dlp что бы он мог решать капчу и получать все доступные варианты видео.
Не совсем, свежие версии таки выносят вспомогательные задачи в отдельные потоки. Но тут максимально простой случай где и кэш скорее всего в принципе не нужен.
SFTP итак поверх ssh работает, можно конечно пробросить любой порт через ssh, но это отнюдь не элегантно и удобно. Да и по скорости уступает samba и прочим...
Разный тепловой поток, у ryzen площадь кристалла в несколько раз меньше чем у epyc а общий тдп отличается всего в двое, да и старшие epyc на 300+ ватт идут с СЖО, мы рассматривали серверы с двумя epyc и все что выше 300 ватт на проц на СЖО.
А ещё к комменарию выше, "стойки" для иммерсионного охлаждения это горизонтальные ванны, что занимает большую площадь, и нельзя просто так поставить в имеющий я зал.
Если честно не встречал, hpe superdome flex может отключить сбойную планку и продолжить работу, но что бы её заменить надо таки выключить сервер... Кроме мейнфремов не слышал про горячую замену чего-либо кроме дисков, блоков питания и куллеров.
Скорость они тротлят так что бы касалось примерно со скоростью просмотра, что бы качальщики не занимали канал.
все бы везли из-за границы, т.к. у автоваза качество страдает)
Не сказал бы, возможно большинство просто не в курсе что можно лучше, лично я по той же причине не пользуюсь стримингами, лучше вообще не смотреть чем смотреть на кашицу из пикселей и градиентные квадраты в темных частях кадра...
Хотя в части причин я может и не прав, т.к. по моим наблюдениям даже на трекерах раздачи в 720р с шакальным качеством более популярные чем более качественные варианты.
А в части стриминга проблема не только в качестве, но и в том что даже с гигабитным подключением не всегда удаётся смотреть видео в 1080 без подгрузок и подвисаний, то ли CDN перегружены то ли каналы провайдеров, я уж молчу про мобильный интернет за пределами крупных городов...
Вот вообще не факт, сам процесс может потреблять больше энергии но он может быть сильно короче за счёт чего общее потребление меньше. хотя в рамках задачи воспроизведения видео с фиксированной продолжительностью возможно экономии не будет. Хотя остаётся вопрос удобства, заикающееся на 15 секунд каждые 5 секунд видео, даст больше негатива чем чуть более быстрый разряд аккумулятора.
Ну тут на самом деле может быть несколько факторов:
Если это не коммерческий проект с солидным бюджетом на оборудование и монтаж, то оно вероятно изначально снималось на тапок и монитровалось на третьем пентиуме, хорошо если там будет x264 с не самым быстрым пресетом в 720р.
Как показано в статье видео может быть недостаточно популярным что бы гугл решил перекодировать его в более качественные кодеки, особенно в сочетании с его малым размером из-за пункта 1.
В последнее время гугл ввёл JS капчу и если её не решить он не отдаёт видео вообще или отдаёт только самые низкокачественные, yt-dlp не умеет из коробки их решать, нужно ставить JS и плагин для yt-dlp что бы он мог решать капчу и получать все доступные варианты видео.
Да, просто поменяй порядок в переменной
Если нет многопользователького доступа то и объем не критерий...
Не совсем, свежие версии таки выносят вспомогательные задачи в отдельные потоки. Но тут максимально простой случай где и кэш скорее всего в принципе не нужен.
Ну в случае бд без кэша нет необходимости инвалидировать кэш...
Ну кэши обычно добавляют для ускорения работы, а не что бы был и если скорости СУБД без него достаточно то нет смысла усложнять проект.
SFTP итак поверх ssh работает, можно конечно пробросить любой порт через ssh, но это отнюдь не элегантно и удобно. Да и по скорости уступает samba и прочим...
С самого сервера тоже есть доступ, так что если попасть в ОС тоже можно эксплуатировать эту уязвимость, причём рут не нужен.
Разный тепловой поток, у ryzen площадь кристалла в несколько раз меньше чем у epyc а общий тдп отличается всего в двое, да и старшие epyc на 300+ ватт идут с СЖО, мы рассматривали серверы с двумя epyc и все что выше 300 ватт на проц на СЖО.
А ещё к комменарию выше, "стойки" для иммерсионного охлаждения это горизонтальные ванны, что занимает большую площадь, и нельзя просто так поставить в имеющий я зал.
Если честно не встречал, hpe superdome flex может отключить сбойную планку и продолжить работу, но что бы её заменить надо таки выключить сервер... Кроме мейнфремов не слышал про горячую замену чего-либо кроме дисков, блоков питания и куллеров.
А в таких системах важно не количество ядер, а производительность на ядро. Для многопоточной нагрузки классические серверы на xeon или epyc выгодней.
Скорее всего бэкпортируют в 9 и 10.
Это да но я именно про службу телеметрии
Таки аналогичная ситуация на рабочем ноуте, только он слабее и там под 80% cpu съедает...
А как физический формфакторе и коннектор влияет на возможность организации рейдов?