Можете объяснить алгоритм как синхронизовать 200 000 файлов так, чтобы это было быстро? Не применительно к nextcloud, а вообще как алгоритмическую задачу?
У колонок проблема не в способе ввода, а в способе вывода: только звуковой (ну и взаимодействие с IoT). Там где нужно сделать выбор (пиццу, что-то еще), смартфон (в котором есть голосовой ввод тоже) становится намного удобней в плане интерфейса взаимодействия с выведенной информацией.
Поэтому колонки подходят там, где можно дать четкую однозначную команду с предсказуемым результатом (типа "поставь будильник на 8:00").
Приделать бы к колонке экран, чтобы вывод был... тут мы и получим приставки к ТВ от Сбера -)
Так как ТВ есть у всех, колонки без подключения к ТВ - тупиковый путь развития, так как вывод у них только голосовой.
Ну и да, правильно поставленный автором вопрос как партнеры с колонки будут зарабатывать.
Но в итоге все равно выходит, что смартфон, у которого есть и голосовой ввод и сенсорный и голосовой вывод и вывод на экран получается намного гибче.
Колонка в качестве части экосистемы и контроллера IoT? Ну может быть, но как выше описал, подключив ее к ТВ можно сделать более полезное устройство.
Дак открыть поисковик, там в голосовой ввод: "заказать пиццу рядом на заказ вкусная хорошие отзывы". Разница с колонкой по трудозатратам - приложение запустить и все.
Зато со смартфона ты не только слышишь, но и видишь результат и можешь сделать более осознанный выбор.
Раньше было так, ага. Но там был и элемент отбора (не любой чип процессора на максимальной частоте заработает, такие шли в более слабые модели).
Теперь сегментация за счет количества ядер (и немного частоты).
Ну и здесь прикол не в том, что что-то заблокировано в дровах (как в видеокартах раньше) или дорожки лазером перерезаны (как в процессорах), а что можно за деньги включить.
Особенно это эпично будет выглядеть, когда проц покупают за 3000$ в сервер общей стоимостью 12000$, а на дополнительных фичах экономят какие-нибудь 500$ прошивая непойми какой прошивкой с китайских форумов.
Ну сервера на Intel/AMD/ARM в аренду взять можно очень давно. Но наверное да, во всяких промышленных станках разблокировка фич за деньги наверное тоже есть очень давно.
Ну если надо хранить глобально несколько экземпляров вместо синглтона, то шаблон давно известен: мультитон. Правда тут вопрос как понять, когда экземпляры в мультитоне надо убить, если вдруг их там может быть порождено очень много.
Начали появляться аппаратные кодировщики AV1 (NVidia 4xxx и Intel ARC), аппаратные декодировщики уже давно есть в новых видеокартах. Если это все сможет и в AVIF, то преимущества JPEG XL по качеству кодирования уже не кажутся столь однозначными, как указано в статье.
Ответ вероятно очень прост: запись в журнал однопоточная. Когда вы уменьшили в 2 раза число потоков, вы уменьшили нагрузку, вот задержка и уменьшилась. Ну а как многопоточно писать в файл журнала еще с гарантией согласованности, если не одним потоком? Ну по крайней мере в MySQL запись точно однопоточная, а про MS SQL не знаю.
Вообще тезис можно перевернуть: когда увеличение числа потоков записи не изменяет задержку? Тогда, когда дисковая система не нагружена, в нее ты пишешь больше и она прожевывает. А когда с ростом потоков растет задержка - это говорит, что внутри хранилки вы во что-то уперлись и там очередь создается. Отправили в два раза больше нагрузки, она в два раза дольше пишется - это же явный признак бутылочного горлышка.
Ну я уверяю, тормозит не загрузка изменений, а сам факт определения, что какие-то файлы изменились.
Да, предложенный вами метод не учитывает, что файлы в момент синхронизации могут изменяться и на сервере и на клиенте.
Ну сходу нагуглил, хотя сам не пробовал: https://play.google.com/store/apps/details?id=com.cuntubuntu&hl=ru&gl=US
Ну и KVM вроде на Android завезли, так что при желании можно запускать и другие дистры.
Вместо домашнего животного, чтоб жрал и визжал.
Можете объяснить алгоритм как синхронизовать 200 000 файлов так, чтобы это было быстро? Не применительно к nextcloud, а вообще как алгоритмическую задачу?
Нет, когда ему привезут один раз ниже его ожиданий, он перестанет пользоваться колонкой для заказов. Ну ладно, может 2-3 раза потерпит и все.
У колонок проблема не в способе ввода, а в способе вывода: только звуковой (ну и взаимодействие с IoT). Там где нужно сделать выбор (пиццу, что-то еще), смартфон (в котором есть голосовой ввод тоже) становится намного удобней в плане интерфейса взаимодействия с выведенной информацией.
Поэтому колонки подходят там, где можно дать четкую однозначную команду с предсказуемым результатом (типа "поставь будильник на 8:00").
Приделать бы к колонке экран, чтобы вывод был... тут мы и получим приставки к ТВ от Сбера -)
Так как ТВ есть у всех, колонки без подключения к ТВ - тупиковый путь развития, так как вывод у них только голосовой.
Ну и да, правильно поставленный автором вопрос как партнеры с колонки будут зарабатывать.
Но в итоге все равно выходит, что смартфон, у которого есть и голосовой ввод и сенсорный и голосовой вывод и вывод на экран получается намного гибче.
Колонка в качестве части экосистемы и контроллера IoT? Ну может быть, но как выше описал, подключив ее к ТВ можно сделать более полезное устройство.
Во-во. Если человек вдруг захочет колонку и купит не из твоей экосистемы, то чужая колонка может стать каналом утечки платящего клиента.
Дак открыть поисковик, там в голосовой ввод: "заказать пиццу рядом на заказ вкусная хорошие отзывы". Разница с колонкой по трудозатратам - приложение запустить и все.
Зато со смартфона ты не только слышишь, но и видишь результат и можешь сделать более осознанный выбор.
Ну, может потом сделают сказки за рекламу:
"Посадил дед репку. Да не где-нибудь, а в самом крупном сельхоз магазине в Москве X, выросла репка на удобрении Y большая-пребольшая!
Раньше было так, ага. Но там был и элемент отбора (не любой чип процессора на максимальной частоте заработает, такие шли в более слабые модели).
Теперь сегментация за счет количества ядер (и немного частоты).
Ну и здесь прикол не в том, что что-то заблокировано в дровах (как в видеокартах раньше) или дорожки лазером перерезаны (как в процессорах), а что можно за деньги включить.
"Зашей в процессор вирус бесплатно".
Особенно это эпично будет выглядеть, когда проц покупают за 3000$ в сервер общей стоимостью 12000$, а на дополнительных фичах экономят какие-нибудь 500$ прошивая непойми какой прошивкой с китайских форумов.
Ну сервера на Intel/AMD/ARM в аренду взять можно очень давно. Но наверное да, во всяких промышленных станках разблокировка фич за деньги наверное тоже есть очень давно.
Фичи в IPMI же продают за деньги. Вот и процессоры тоже.
Хотя как по мне, это противоречит зеленой повестке (тратить энергию на производство того, что потом отключено).
Ну если надо хранить глобально несколько экземпляров вместо синглтона, то шаблон давно известен: мультитон. Правда тут вопрос как понять, когда экземпляры в мультитоне надо убить, если вдруг их там может быть порождено очень много.
А что сделать-то могли? Сейчас плагины можно только на JS писать. Ну да, еще WebAssembly.
Нет, проблем было бы * X браузеров не умеющих JPEG XL.
Начали появляться аппаратные кодировщики AV1 (NVidia 4xxx и Intel ARC), аппаратные декодировщики уже давно есть в новых видеокартах. Если это все сможет и в AVIF, то преимущества JPEG XL по качеству кодирования уже не кажутся столь однозначными, как указано в статье.
Но прогрессивность - да, это удобно.
Согласен, до 2016 лог был однопоточный, затем многопоточным стал.
Ответ вероятно очень прост: запись в журнал однопоточная. Когда вы уменьшили в 2 раза число потоков, вы уменьшили нагрузку, вот задержка и уменьшилась. Ну а как многопоточно писать в файл журнала еще с гарантией согласованности, если не одним потоком? Ну по крайней мере в MySQL запись точно однопоточная, а про MS SQL не знаю.
Вообще тезис можно перевернуть: когда увеличение числа потоков записи не изменяет задержку? Тогда, когда дисковая система не нагружена, в нее ты пишешь больше и она прожевывает. А когда с ростом потоков растет задержка - это говорит, что внутри хранилки вы во что-то уперлись и там очередь создается. Отправили в два раза больше нагрузки, она в два раза дольше пишется - это же явный признак бутылочного горлышка.
Видел, что проиграл, ага. Это не значит, что результаты неправильные. Одну из возможных причин вы в п. б назвали: особенности реализации рамдиска.