mayton2019, вопрос был о другом. Кстати, очень хороший вопрос. Вспомните про e-ink - какая у него частота кадров? :) А никакая. То есть нулевая, казуальное обновление экрана, хоть сто лет между сменами кадров. И это желанная характеристика. А что там с технологией LCD, есть у неё что-то такое, что мешает сделать нулевую частоту кога захочется? Почему нельзя было сделать протокол передачи данных от видеоадаптера к монитору похожим на RDP (не буквально, а в плане отсутствия передачи, когда на экране ничего не меняется)? Может быть, виноват маркетинг? Нельзя позволить потребителям думать на эту тему.
Очень верное замечание насчет eInk. У этого устройства вообще нет пост-свечения. Есть просто подложка
с пузырьками чернил которые кувыркаются и показывают градации серого. И для него мы вообще не
сможем придумать формулу которая-бы точно связала требования анимации и технику. Скорее
мы можем сказать что время реакции eInk пиксела настолько медленное что лучше читать книги
чем смотреть Gif файлы или mp4, и прочее. Даже сама попытка реализовать видеоплеетр - изменит
энергопотребление книжки и она будет садить батарею как мобила а не как гарантирует
производитель (до нескольких неделль без перезаряда). Потреб-характеристики тоже важны.
Ведь главный полезный эффект е-Инк - это нулевое потребление энергии когда нет изменений в кадре.
Василий Банников, это - психофизиология. Самые ранние версии синематографа делали несколько герц.
Несколько кадров в секунду. И это были предельные ограничения техники тогда. Просто быстрее
нельзя было снять кино. Экспозиция тоже занимала время. А пленка была еще слабо чувствительная.
Многие решения 20-го века (система PAL) где есть чрезстрочное дрожание луча между кадрами
решало техническую проблему. Надо было убрать черную решетку между строками. Вот так и появился
interlace который и сегодня можно видеть в оцифровках VHS кассет. Для кино - интерлейс не нужен например.
nnn Xion, чел. Масштабирование - это не вынос логики в Redis.
Если ты хочешь реального масштабирования то ты должен писать задачу так чтоб она работала
в кластере на одно-ранговых узлах (нодах) и ее внешняя бизнес логика выглядела бы так будто
это работает 1 физический хост. И если ты правильно все сделал - то чтоб ускорять (масштабировать)
такое приложение тебе ничего не надо больше. Только добавляй новые ноды в кластер.
А Редис - вообще не про это. Редис решает другие задачи хотя он может что-то ускорять.
А каким образом мы проверим вообще из какого города? По IP адресу? По пользовательскому профилю?
Вы говорите о кукисах, но это просто один из способов ведения сессионных переменных на стороне
клиента. И когда проектируется надежная система то в первую очередь нужно проверять кукисы и не
доверять. Иначе чел с ноутбуком будет ездить везде и толкать данные все равно в одну и ту-же базу.
Вот эту механику с городами нужно прояснить на уровне ТЗ или User Story.
Vincent1, на segmentation fault у меня нет ответа. Нужно смотреть глазами этот дамп. Но вряд-ли
кто-то в хабре согласится забезплатно тебе такую услугу оказать.
Попробуй скачать исходники скальпеля и пересобрать его под свой ubuntu22.
Вы зря спорите. Потому что торрент-клиенты используют 4 или 5 разных протоколов одновременно.
Есть централизованные которые требуют наличия трекера. И есть те, которые основаны на
разспределенном хранении информации (DHT, PEX ...e.t.c). И сами Торрент клиенты могут
расширять и дополнять свои протоколы (Vuze). Нет единого стандарта и контроля за разработкой
подобных клиентов. Нет консорциума которые что-то регулирует.
Под динамическием соединением - непонятно что автор имеет в виду. Во первых открытие порта
нужно только для инициации соединения извне. Если твой клиент инициирует - то это почти всегда
разрешено. Вот так и происходит соединение.
Для комфортной работы всех протоколов в клиенте есть self-test который проверяет доступность портов
снаружи. Пускай автор проверит что у него открыто.- Это наверное и будет ответ а вопрос.
Пропускная способность - это вообще прикладной уровень и рассматривать его здесь не интересно.
Как написано приложение - так и регулирует.
В криптовалютах нет арбитра. И любые ошибочные операции обычно безвозвратны. И не к кому
пойти чтоб отменить транзакцию.
Крипта также сильно подвержена спекуляциям, и очень сложно договариваться об оплате по курсу.
Твой кошелек прозрачен для постороннего наблюдателя. С одной стороны это крипто. С другой стороны
- стена на которой все пишут и читают что хотят. Возможно есть боты которые коллектят бигдату
по кошелькам и ты и твой баланс будет объектом наблюдения посторонних людей с неизвестными
целями и явно не очень хорошими по отношению к тебе.
Иерокопус Таманский, предложите ваш вариант. Я писал что это - восстановление с вероятностью. Для фоток - хорошо пойдет. Для видео - можно получить битые файлы.
Беря во внимание что был сделан дамп - можно экспериментировать бесконечно, проверяя разные
опции восстановления. И только владелец может сказать достаточно ли восстановлено или нет.
pfg21, когда делают бекапы. Есть разные хитрости и стратегии. Например делают перидические копии.
Еженедельно например. В случае стримера у тебя есть пул касет. Ты их меняешь по кругу. И если одна кассета повреждается то у тебя есть двухнедельная копия.
Техники инкрементального копирования позволят тебе копировать не все а только то что изменилось.
Для повышения надежности копий я добавляю дополнительны коды восстановления. Есть утилиты типа par2.
Мне кажется что проблема применения нейросетей в бизнесе и хозяйстве очень похожа на поиск
готовых Delphi-компонентов в 90х которые коробочно решали какую-то узкую задачу.
Беря во внимание что постановок можно придумать - миллиионы, особенно с машинным зрением,
то и также будут нужны миллиоды инженеров по ML чтоб закрывать эти потребности.
Dahock, я не помню чтоб я читал какую-то книгу про это. Поищи по ключевым словам vector database,
text search, word2vec, tf-idf, HNSW .
Из программных продуктов. Postgres, Redis, Apache Spark, Apache Lucene, Sphinx . Они могут поддерживать
какие-то алгоритмы или принципы поиска документов по подобию.
Очень верное замечание насчет eInk. У этого устройства вообще нет пост-свечения. Есть просто подложка
с пузырьками чернил которые кувыркаются и показывают градации серого. И для него мы вообще не
сможем придумать формулу которая-бы точно связала требования анимации и технику. Скорее
мы можем сказать что время реакции eInk пиксела настолько медленное что лучше читать книги
чем смотреть Gif файлы или mp4, и прочее. Даже сама попытка реализовать видеоплеетр - изменит
энергопотребление книжки и она будет садить батарею как мобила а не как гарантирует
производитель (до нескольких неделль без перезаряда). Потреб-характеристики тоже важны.
Ведь главный полезный эффект е-Инк - это нулевое потребление энергии когда нет изменений в кадре.