mayton2019

Incscape по идее умеет переводить растровые картинки в вектор.
Но результат будет сильно зависеть от качества исходной картинки.

Вариант

$ oggdec file_example_OOG_5MG.ogg file_example_OOG_5MG.wav
$ lame file_example_OOG_5MG.wav

И из Go соотвественно надо вызвать внешний процесс

exec.Command(".....")

Геркон - это выключатель. Пассивное устройство. И он ничего не потребляет. Поэтому можно
включить их бесконечно много. Насколько хватит денег.

Возможно к 20 пинам подключить 100 клавиш клавиатуры. Но надо как-то с самим собой
договориться что мы не будем играть в игры и давить сразу 2 или 3 клавиши одновременно.
Кажется такая схема в старых кнопочных телефонах использовалась где были цифры от 0 до 9
и символы * и #

Документация упоминает утилиту

gcloud firestore export ...

https://firebase.google.com/docs/firestore/manage-...

Попробуй сохрани базу в файл. Если он имеет вид JSON то тебе повезло.

Классические реляционные СУБД (MySQL) плохо приспособлены к хранению бинарных
файлов. Все дело в размере строки. Исторически 1 строка (data_row) в БД не превышала 4-8 килобайт.
Исходя из этого ограничения БД проектируют кеш и алгоритмы когеретности по кешу.
И все работает отлично до тех пор пока вы не начинаете миксовать крупные файлы и строку БД.
В этом случае мехнизм кеширования БД ломается и БД вынуждена ходить в disk (tablespace)
который по total cost of ownership всегда стоит дороже чем обычный диск, и тем более дороже
чем хранилище AWS/MS-Blob/GDrive. Дороже будет стоить бэкап базы данных которая на 95%
к примеру состоит из JPG картинок вместо реляционных данных. Такова специфика дискового
пространства почти любой БД. Не удивляйтесь если облачный биллинг вам выкатит счет
по которому JPG картинки будут стоить как крипта. Дороже будет сетевой траф для публикации картинки
ведь вам надо сделать сначала трансфер этих мегабайтов с хоста MySQL в Node/Tomcat/Apache
и лишь только потом сделать еще один трансфер с веб хостинга к клиенту. Трафик - 2x.

Поэтому имеет смысл толстые картинки положить в обычный диск под веб сервером Apache
или пошарить хранилище через web-endpoint. В этом случае биллинг за хостинг картинок
для вас станет хотя-бы разумным. А в реляционной базе хранить тольк URL на этот диск.

Некоторые советы по вопросу. Первое.

Совет бывшего создателя - убивать приложения через taskkill конечно очень порадовал.
Было-бы неплохо чтобы создатель также помог автоматизировать процедуры восстановления
файлов и данных после такой спорадической стрельбы. Вообще не существует не-деструктивного
способа забрать выделенную память у приложения. Таковы реалии. Если программист зачем-то
выделил память - значит нужно. И фиксацию этого можно сделать только в исходном коде
приложения.

Второе. Если вы - сисадмин, который занимается развертыванием и сопровождением программных
продуктов то вам должны были дать инструкции по всему этому. Поищите в документации
секцию настройка или configuration. Там должно быть что-то вроде buffers, threads, workers, memory_pool e.t.c.
В ini files или в реестре.

По терминологии. Никакого ОЗУ уже давно не существует с точки зрения приложений. Это - старый
термин из 20-го века и его надо как-то убрать из вопроса. Современная память приложений - это
virtual memory которая представляет собой бутерброд из ОЗУ и Paging File (Swap file в разных ОС).
По факту приложения могут выделять больше памяти чем есть в ОЗУ но при этом сохранять свою
работоспособность. Но механика сброса страниц или чтения может сыграть роль performance issue,
которое надо оценить в виде метрики.

Поэтому если автор хочет понять влияние памяти на приложение - я вижу единственный вариант
- придумать метрику работы приложения (например количество отработанных транзакций в секунду
в нормальном (номинальном) режиме работы) и запомнить ее. Это будет base line или некая хорошая
горизонтальная линия на графике. Или какой-нибудь квартиль или процентиль от времени отклика.
Далее - наблюдать эти графики в Grafana или каком-то другом графическом мониторинге.

По поводу процессов сsc.exe и conhost.exe. Это - консоль и компиллятор Microsoft C#. Тут - мало информации
к расследованию. Скорее всего их наличие - это просто дизайн и архитектура. Но если автору интересно -
пускай поищет командную строку (те символы которые идут после csc.exe). Возможно будет какая-то
более ценная инфа.

Современные процессоры уже кодируют mp3 быстрее чем требуется для онлайн трансляции.
Поэтому острой необходимости нету. По поводу CUDA я не специалист. Но практически все
задачи подобного толка решаются через шаблоны fork-join.
Если ты сможешь взять поток mp3 и порезать его на совокупность кадров. И для каждого
кадра очень эффективно создать этот самый fork-join и успеть очень быстро собрать результаты
всех потоков в новый поток - то твоя задача вполне себе осуществима. Но будет ли от этого
ощутимый эффект - чорт его знает. И не будет ли потерь на координации ядер и потоков.
Задачи майнинга к примеру выигрывают на том что у них редкая координация. Раз в 10 минут
получили задание - загрузили каждый камень и спокойно себе считают. С mp3 будет по другому.

Несколько мыслей.

Копировать рабочие станции - это впустую тратить дисковое пространство. Имеет смысл изучить ценную
информацию на десктопах и копировать их точечно. Например - копировать только Мои Документы.
И только файлы определенной сигнатуры.

Настройки приложений - по максимуму вынести в домен-контроллер. В идеале все настройки должны там
быть.

Сам процесс копирования не имеет смысла без тестов восстановления.

Непонятно каким образом вы от проблемы PostgresQL перешли к проблеме zfs?

Мне кажется что существует только один способ проверки работоспособности снепшота.
А именно - сразу после того как он сделан - поднять на нем БД и посмотреть что в журналах
нет ошибок. Если ошибки есть - повторить снепшот еще раз.

Sad, but true.

RandomAccessFile, FileInputStream - это абстракции поверх системного I/O. В идеале они должны
иметь всего 1 метод. Чтения блока байтов в буфер. Но идя навстречу разработчику они любезно
добавили чтение примитивов чтоб читать двоичные форматы например JPG, MP3, SQlite и прочее
в виде sequence из примитивов в правильном порядке.

Технически, любая ОС убирает память после завершения процесса. На этом основан
life-cycle PHP странички например. Обработка PHP-responce - это запуск одного
(обычно) Linux процесса.

Можно использовать фильтр Блума. Тогда для твоего числа ключей (4 320 000 000) надо
будет держать структуру размером 4.8 Гб https://hur.st/bloomfilter/?n=4320000000&p=0.01&m=&k=

Но фильтр отбивает не 100% ответов а просто некую большую часть (99% в данной формуле). И поэтому надо чтобы
в базе всегда стоял unique constraint. Да и вообще констрейнт - это часть культуры проектирования
баз. Поэтому это даже не должно обсуждаться. База без гарантий уникальности - это сильно
подпорченная информация. Информация низкого качества.

Фильтры Блума используются в Cassandra, Hadoop, Databricks, Redis. Обычно не как основные а как
вспомогательные структуры. Поэтому такие решения - вполне себе production-ready.

Кажется APK - это zip архив. Поэтому контрольные суммы типа CRC-32 должны отслеживаться при
распаковке.

Мда. Такую схему проще было реализовать в 90х- 2000х на аналоговой технике.
Если 1 блютус заменить на проводной наушник и купить head-phone splitter
то можно слушать вдвоем. Сильно много ушей вешать на 1 выход нежелательно.
Это все таки слабомощная штука.

Тебе чтобы глянуть сертификат - безразлично какая версия JDK. Потому что стандарты
криптографии - это вообще отдельная тема.

Поставь себе временно JDK-21 и спокойно посмотри все подписи.

Еще зайди внутрь apk файла и поищи саму подпись. Можно найти глазами.

Я не специалист в кликхаусе, но если ты указываешь

ENGINE = ReplacingMergeTree
Order by (....)

то это (скорее всего) включает некоторые механизмы дедубликации. Почитай вот тут пишут
https://clickhouse.com/docs/en/engines/table-engin...

Выше ты писал

должны убраться дублирующиеся записи, но их нет.

это нужно доказать отдельным SQL запросом. Я думаю что ты скорее всего ошибся.
Проверь.

Если у тебя нет опыта ремонта электрики и электротехники - то лучше ничего не делай. Неси
в ремонт. БП - это опасное напряжение. И лучше туда не лезть без соотв. знаний.