mayton2019

Попробуйте так.

wget -r -l1 -nd -A jpg,jpeg,png,gif https://example.com

Это работало для классических сайтов (.html / WEB 1.0) где контент был статичным.

К сожалению современный веб контент это вообще ни разу не сайт. Это динамический
документ который генерируется JS приложением прямо в браузере. И чтобы полноценно
создать такой контент вам нужен браузер или шука похожая на Selenium. Иммитатор браузера.
Это требует процесса разработки. Тоесть нужен программист.

Утилиты наподобие wget, curl, httrack работают только со статическим html и не могут гарантировать
что картинки будут скачиваться всегда.

Короче - это опция. Может сработать и может нет.

Автор пишет

Ну и пример: вот есть у меня программа, которая делает простой инкремент числа, допустим. По сути это равносильно тому, что в некий регистр запихали значение и сделали инкремент в цикле, а ля

mov ax, 0
inc ax.

Будет ли данная программа получать какой-то выигрыш от увеличения количества транзисторов на кристалле при равной тактовой частоте процессора и если да, то как?

В данном конкретном случае никаих миллиардов транзисторов не нужно. Задача инкремента
действительно решается на десятках лампочек и реле или если хотите транзисторов.

Но технологически, число транзисторов это метрика которая грубо показывает сложность
устройства на кристалле. И ядерность. Технологически, компании производящие железо заинтересованы
делать кристалл меньше и число транзисторов больше. Это показывает их техно-превосходство.
Почему кристал меньше - понятно? Иначе он был-бы размером с чемодан или шкаф например.
Что уже десктопом не может быть. И энергопотреблял бы как хорошая электроплитка.

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

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

1) Можешь смело брать sha256/512. Они уже имеют аппаратную поддержку в процессорах и должны быть быстрее чем MD5. Проверь этот факт для твоего API.

2) По поводу борьбы с коллизиями. Нужно посчитать цену коллизии. Тоесть если она все таки
возникает - как это повлияет на ваш бизнес. И как вы будете выходить из ситуации.

Вообще я думаю что все будет в порядке. 350 млрд. Номерная емкость SHA256 - это 1.157920892373162E77
и доля ключей составляет 3.0226589942830556E-66.

Это буквально 0 процентов. Ноль целых и потом 60 нулей после запятой.

4 минуты это нормально. Это как машину в гараже зимой завести. Тебе-же не каждые 5 минут
заводить надо? Завел и оно год работает.

По поводу SVGA и прочего. Да. Для серверов это тоже нормально. Ты-же собрался в нем
считать математику, а не в игры играть. Да и вообще для удаленного доступа тебе видяшка не к чему.

import platform
os_name = platform.system()
print(os_name)

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

Пускай учатся работать аккуратно. Это более ценно чем "кирпичить" умные устройства.

В Андроиде насколько я помню есть API для работы с SQLite БД. Это в тех случаях
когда тебе надо экономить память но и работать с данными тоже надо.
Можно попробовать 1 раз скачать список станций и считая его достаточно
стационарным - положить в БД и потом делать с ним joins из других запросов.

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

Начинающая компания (стартап) - это шайка друзей у которых есть тесные горизонтальные
связи чтобы работать вместе. Иногда дружеские. Иногда родственные. Кум. Брат. Любовница.
И по большему счету вам будут не сильно рады. Потому что им придется делить общий пирог с вами.
Подумайте зачем вы вообще нужны в такой шайке?

Смотри. Символ с кодом 0x0000 не является запрещенным с точки зрения Utf8.

Но его использование c/c++ языках и в системных коллах может создать проблемы.
Поэтому в рамках хабра и в такой постановке вопроса мы скорее всего не знаем
что с этим делать.

Уменьшить длину можно строковыми операциями в языке C#, но мне кажется что
это не есть главный вопрос.

Коробочное решение шифрования - это nginx

https://nginx.org/en/

вот эта штука с initdb выполняется секунд 10-20 поэтому её похоже приходится делать на старте (а можно ли как-то ускорить?)

Да. Это похоже на правду. В качестве утешения могу сказать что Azure AKS контейнеры могут и
больше 1 минуты стартовать независимо от содержания.

Для организации песочницы вам надо поднять пул хотя-бы 5-10 таких контейенров и подключать
клиентов уже к горямим, которые подняты. Можно их после сессии не тушить и поддерживать.

Вопрос с переполнением памяти или с биллингом - подбирается эмпирически, исходя из
актуальных условий. Вряд-ли мы сейчас, поплевав в потолок сможем придумать что-то актуальное.

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

Я-бы предложил не сжимать всю базу а проанализировать, какие таблицы и какие поля занимают
80% всего пространства. (Процены я взял с головы по принципу Паретто. Вы можете взять любой
процент. Можно 90 или 70 не суть важно. Важно чтобы не закапыватья м мелочах.)

Из опыта других БД. (Не MS-SQL). Часто бывало что потребителем места были BLOB-поля где
лежали какие-то несуразные и никому не нужные документы. Аттачменты. Картинки. Копии
email из переписок с пользователем и многое другое. Были ситуации когда причиной роста
БД были старые архивные записи в таблице которые почему-то были забыты. Они должны
были удаляться но из за бага не удалялись.

Хорошая практика в данном случае - убрать из БД все длинные текстовые документы
или положить их в gzip на уровне самого приложения например. Обычно такие поля
не участвуют напрямую в операциях OLTP и их сжатие ни на что особо не влияет.

Почти все современные БД имеют очень хорошую плотность информации на мегабайт
и если админ что-то там шринковал или уплотнял - то это носит временную меру. Через
некоторое время БД возвращается к той плотности как и была раньше вследствие
updates например.

По поводу ROW level/block level сжатия. Я не специалист в MS_SQL, но обычно это надо
предварительно тестировать под нагрузкой на PROD для всех DBMS в общем то.
Велика вероятность падения производительности а это, сами понимаете слишком
большая цена за экономию. И диски в наше время значительно дешевле скажем чем 10 лет назад.

Лучше параллельно все записывать в аудио. Диктор может шепелявить, гундосить или бубнеть
и там ни одна нейросеть не поймет потому что она не в контексте.

А вы, как слушатель - в контексте. Вы - знаете что ожидать от невразумительного мычания.
Поэтому НС идут своим чередом. Но аудио придется тоже хранить.

Excel я сделал форму, кнопки, добавить расходы, доходы, добавить пользователя.. жму и выполняется sql запрос и база заполняется...

Напоминает старый анекдот про "сделайте мне лялю"...

Данное техническое задание стоит денег. Я точно уверен что универсального решения здесь не может
быть, потому что слишком много вопросов. Много условностей и договорняков на словах.

Экспорт-импорт из Excel в PG это задача решенная. И она даже не требует разработки. Это скорее
всего работа квалифицированного пользователя и дата инженера.

А вот все что касается формочек и кнопочек, нужен разработчик. И детальное ТЗ.

Обычные архиваторы скорее всего не делают дедубликации.

Но предварительно можно сделать такое

FLEngine_x64.dll
FLEngine_x64_Copy1.dll => symlink FLEngine_x64.dll
FLEngine_x64_Copy2.dll => symlink FLEngine_x64.dll
FLEngine_x64_Copy3.dll => symlink FLEngine_x64.dll
FLEngine_x64_Copy4.dll => symlink FLEngine_x64.dll
FLEngine_x64_Copy5.dll => symlink FLEngine_x64.dll

и попробовать zip/tar. Они вроде умеют симлинки оптимально хранить.

В данном задании непонятно насколько остро стоит необходимость именно в MQ системе.

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

Для автоматизации тестирования - посмотри Robot
https://docs.oracle.com/en/java/javase/21/docs/api...
но его функционал в основном завязан на графические приложения
созданные с java.awt.

У звукорежиссеров это кажется называется pitch.

Берется дилетант который не умеет петь но очень хочет. Он напевает что-то.
Потом звуковик редактирует темп и тональность.

Полу-ручная работа. Здесь еще не хватает самой композиции. Ее надо придумть.
Про это автор не пишет. Возможно ему все равно что там будет.

Тогда проще всего не петь а прочитать рэп по тексту.

То что автор перечислил - это best practices. .

Архитектурный вопрос например - это инвалидация кеша.
Протоколы кворума. Консистентность данных в распределенной системе.
Перформанс в сложной системе. Это тоже архитектура.