mayton2019

Вот привык я к ШИНДОВС, а в ней программы устанавливаются через *.msi или *.exe файлы.

Да ты - старый дед! :) Все админы и девопсы при использовании Windows ставят себе пакеты через
"шоколядку" (chocolatey) https://chocolatey.org/

Вот как я себе ставил поддержку zip в консоли

PS C:\Windows\system32> choco install zip
Chocolatey v2.2.2
Installing the following packages:
zip
By installing, you accept licenses for the packages.
Progress: Downloading zip 3.0... 100%

zip v3.0.0 [Approved]
zip package files install completed. Performing other installation steps.

Вот привык я к ШИНДОВС...

Я кстати очень не одобряю твою культурную апроприацию к Linux-сообществу (ЛОР и прочее). Только
они имеют моральное право говорить Маздай, Шишдовс и так далее. А ты - типичный
виндузятник.

Ты в этом случае выглядишь как фрайер в камере который пытается косить под вора в законе.
Понимаешь?

Ты-же для игр покупал? Обычно опытные геймеры примерно на глаз видят скорость кадров и продергивания
при запуске своей игры. Или запусти тест. Раньше был 3D-Mark. Щас не знаю что но тоже наверное что-то
есть подобное для индекса производительности игр.

Мораль такая. Если ты щепетильный покупатель - то умей обоснованно сказать что тебе мощи данного железа к примеру
не хватает. Это как машину покупать. Сел за руль. Поездил по полигону.

В топике верный совет дали - загрузиться со своего загрузочного диска. Я тоже плюсую.

P.S. Покупал с рук... сам знал риски. Вернись туда с битой. Разнеси там все ... :)

В феврале всегда 28 дней. Использую datetime.

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

Не пойму зачем тебе накое надо.

Технически - можно. Но MongoDb оптимизирована для хранения документов. И если вместо документов
туда складывать фильмы то может оказаться так что вы платите очень много за такие блобы которые
выгоднее держать на файловой системе или на сторедже. Привету пример. Если вы храните
документ в котором десяток текстовых полей и 11 поле - это блоб с фильмом длиной 1.5Гб то
получается что реально полезная для поиска и индексирования информация составляет
менее 1% (!) от общего размера БД. А все остальное - это балласт. Я как бывший базовик
привык что в таблицах БД лежит только полезная и нужная для SELECT ... WHERE информация.
Если эта информация не полезна для поиска - то ей не место в БД.

Хуже того что эти блобы будут вовлечены в процесс планового бэкапа. Даже если они не изменялись.
Может возникнуть кейс когда скопировать БД все таки надо. А копировать тяжело. БД уже превысила
пета-байт просто потому что кто-то захотел фильмы хранить рядом с данными.

Я не специалист конкретно по Монге но вот тут пишут о реализациях хранения блобов https://www.mongodb.com/developer/products/mongodb...

Почитайте.

У меня был комп Электроника БК1001 и ZXSpectrum которые работали на частотах 3 и 3.5 Мгц и никаких
проблем я не испытывал.

Проблемы теоретически могут быть у комьютерных игр которые завязаны на том что 1 тик или один кадр
игровой логики может быть обработан за 1/50 долю секунды к примеру и некоторые игры при замедлении
тактовой частоты могут вести себя странно. Впрочем в каждом кейсе надо разбираться. Странно - не означает
неправильно. Просто разработчик когда писал игру расчитывал на определенную производительность.

Прикладной код, при работе на низких частотах может видеть некоторые аномалии при работе с датой-временем
но это вообще не проблема процессора - а это проблема вашего прикладного кода. Тоесть вы должны были
писать код таким образом что даже припаркованный VMWare не должен крашить вашу бизне логику только
потому что часы резко прыгнули вперед на несколько суток например.

Других проблем вобщем-то не предвидится.

Вот посмотри может это поможет https://www.postgresql.org/docs/current/dblink.html

Докину 5 коп.

Я думаю что никто такую задачу вобщем-то не ставит. И никогда не поставит. Тут не то что Java
а я прошу прощения Cobol не могут никак заменить. Языку - уде более 50 лет возраста.
И хотя проблема касается в основном США, но это просто пример того что код живет очень долго.
У джунов уже седые бороды отрасли :)

Язык Rust вобщем-то создавалася как язых обще-системного программирования с правильным
механизмом управления памятью. И уже если ему и где-то конкурировать - так это там где нужен
отклик (игры или реал-тайм приложения).

Сильные стороны Java сегодня - это большой репозитарий библиотек на все случаи жизни.
Статистика по maven https://mvnrepository.com/ заявляет что 35 миллионов артифактов
имеется в наличии. Можно наверное найти любой драйвер или парсер или любую
либу поддержки сетевых протоколов. Большая часть из них проверена временем.
Production ready. Можно ли говорить о production-ready для Rust - библиотек я не знаю.
Пускай знающие отпишут.

Java - машина с развитым рантаймом. Рефлексия позволяет делать позднее инстанциирование
компонентов через конфиги. И этим очень сильно пользуются во фреймворках. Фактически
если проводить сравнительные анализы Rust и Java - мы встанем перед дилеммой - чем заменить
механику рефлексии в Rust? Создавать рантайм? Но это противоречит идеям системного программирования
или все таки принять как факт что Spring и ему подобные фреймворки принципиально нельзя
воспроизвести в языке статической компилляции таком как Rust.

Если-бы я сравнивал этот язык (Rust) - то ставил бы ему в одну весовую категорию Nim, Zig и прочие
языки "пост-плюсового" периода. И в качестве задач я-бы ставил - разработку игр и драйверов
для операционок. Вот там и тестируйте.

Самому финтеху не всегда нужен рилтайм. Иногда - даже вообще не нужен. В батч-джобах биг-даты
и python нормально работает. Специфика своя там. А критичные части бигдаты (Apache Arrow, Databricks Photon)
- и так переписаны на сях чтобы быстринько search + join работал. В стриминге биг-даты - тоже вобщем-то
CPU не сильно критичен. Там и Node и C# тоже годится в качестве языков. Вобщем задачи - I/O bounded.

Postgres очень быстро паркуется, если надо. Кажется pg_ctl там с аргументами или services stop postgresql.
Вот сделай скриптик.

В парадигме современной BigData, вы должны писать все что приходит на вход.
Как это там обзывают.... ELT (Extract, Load, Transform)
Никто не знает наперед какие данные понядоабятся - поэтому фиксируйте весь raw
трафик. Потом - отфильтруете. Построете материализованные views. Но главное что данные
будут.

Учитывая что clickhouse - column oriented - безразлично 2 поля из 2 выбирать или
2 поля из 2000.

Если хранилище у вас все таки переполнится - (со скоростью 2.5 Гб в день) то тогда уже почистите те
колонки которые стали объективно не нужны после например пары месяцев эксплуатации.

Почитай про conda https://docs.conda.io/en/latest/
Там есть коробочные решения для управления версиями окружения Python/GCC e.t.c.
Поможет или нет - я не знаю. Я использовал это только для Python.

Скачивать какие-то частные версии проектов и компилировать их локально и устанавливать - это
риски. Можно поменять окружение так что потом хрен вернешся назад.

IV не надо запоминать. Он может быть частью вашего программного обеспечения.
Генерируете один раз и кладете в исходники.

Все настоящиее DLL-файлы имеют сигнатуру. Это магическое число (обычно 2 или 4 или 8 байт) которые прописываются в заголовке данного типа и никогда не меняются.

Для DLL я точно не помню но кажется совпадает с Windows-executable. Два символа 'M', 'Z' будут сигнатурой.

Теперь задача - найти все DLL-файлы на дисковой системе и найти один файл-уродец который этой сигнатуры
не имеет. Это и будет твой файл.

Для любого программиста - это задача на 10-20 минут.

Успех мероприятия будет зависеть от двух факторов.
1) Успеете ли вы грузить трафик? Тут я думаю будет все ОК при использовании TimeSeriesDB.
2) Успеете ли вы делать их анализ? И что за анализ? Нужно ли вам для анализа видеть консистентность
между всех приборов? Что за сложные типы данных? Как они будут участвовать в запросе.

Поищи по ключевому слову Stable Diffusion.

Ну для floating point чисел ничего интересного не происходит. Результат будет - бесконечность (Inf).
И эта бесконечность - это вполне себе реальная константа для таких чисел.

Очереди могут обеспечить exactly once. По крайней мере в настройках у многих есть такой параметр.

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

Декларация класса и реализация его методов могут лежать в разных файлах исходного кода (*.h, *.cpp)