Не уходит, сначала он отстаивает я некоторое время в отстойник, т.е. Не доступен для выдачи, срок зависит от оператора. Но учитывая что нет механизма отвязывания номера от всех сервисов, а отслеживать в каком из сотен сервисов требующих авторизацию по номеру ты его использовал мало реально, то на выходе получаем что свежие полученный номер может быть привязан к ВК, банку или ещё где и твой старый соответственно тоже может всплыть все ещё привязанный к чему-то.
Это вцелом проблема использования ограниченных переиспользуемых идентификаторов для авторизации где-либо...
Тут вопрос насколько интегрированный в ОС ИИ будет удобнее отдельного приложения и насколько локальная модель будет производитель, при это не высаживая батарейку за 30 минут и не потребляя большую часть ресурсов хоста....
У китайцев есть какая-то цель и они её придерживаются, на мой взгляд оборудование и по пока не готовы дать хороший результат при локальном использовании.
А как же вариант где KubeVirt поднимает ВМ на железных серверах, а уже в них поды с контейнерами? С дефолтным лимитом в 250 подов тяжело утилизировать железку на 256 ядер и 4тб озу, а маленькие серверы не эффективны по занимаемым юнитам...
И тут уже вопрос как проще админить кластер кубера, когда он сам управляет ВМ или когда этим занимается прослойка в виде VMware...
Не сказал бы, возможно большинство просто не в курсе что можно лучше, лично я по той же причине не пользуюсь стримингами, лучше вообще не смотреть чем смотреть на кашицу из пикселей и градиентные квадраты в темных частях кадра...
Хотя в части причин я может и не прав, т.к. по моим наблюдениям даже на трекерах раздачи в 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 может отключить сбойную планку и продолжить работу, но что бы её заменить надо таки выключить сервер... Кроме мейнфремов не слышал про горячую замену чего-либо кроме дисков, блоков питания и куллеров.
И нейронки хорошо гоняет за счёт 96гб видео памяти.
Не уходит, сначала он отстаивает я некоторое время в отстойник, т.е. Не доступен для выдачи, срок зависит от оператора. Но учитывая что нет механизма отвязывания номера от всех сервисов, а отслеживать в каком из сотен сервисов требующих авторизацию по номеру ты его использовал мало реально, то на выходе получаем что свежие полученный номер может быть привязан к ВК, банку или ещё где и твой старый соответственно тоже может всплыть все ещё привязанный к чему-то.
Это вцелом проблема использования ограниченных переиспользуемых идентификаторов для авторизации где-либо...
Тут вопрос насколько интегрированный в ОС ИИ будет удобнее отдельного приложения и насколько локальная модель будет производитель, при это не высаживая батарейку за 30 минут и не потребляя большую часть ресурсов хоста....
У китайцев есть какая-то цель и они её придерживаются, на мой взгляд оборудование и по пока не готовы дать хороший результат при локальном использовании.
В оригинальной статье, предполагалось что и контейнеры и ВМ запущен 6а железе, а в ВМ уже классические нагрузки.
Не знаю как в самых свежих версиях, увеличение лимита приводил к нестабильной работе кластера.
А как же вариант где KubeVirt поднимает ВМ на железных серверах, а уже в них поды с контейнерами? С дефолтным лимитом в 250 подов тяжело утилизировать железку на 256 ядер и 4тб озу, а маленькие серверы не эффективны по занимаемым юнитам...
И тут уже вопрос как проще админить кластер кубера, когда он сам управляет ВМ или когда этим занимается прослойка в виде VMware...
Скорость они тротлят так что бы касалось примерно со скоростью просмотра, что бы качальщики не занимали канал.
все бы везли из-за границы, т.к. у автоваза качество страдает)
Не сказал бы, возможно большинство просто не в курсе что можно лучше, лично я по той же причине не пользуюсь стримингами, лучше вообще не смотреть чем смотреть на кашицу из пикселей и градиентные квадраты в темных частях кадра...
Хотя в части причин я может и не прав, т.к. по моим наблюдениям даже на трекерах раздачи в 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 может отключить сбойную планку и продолжить работу, но что бы её заменить надо таки выключить сервер... Кроме мейнфремов не слышал про горячую замену чего-либо кроме дисков, блоков питания и куллеров.