lightseeker, уверяю тебя я всегда так разговариваю. Почитай википедию по ключевым словам таким как Двоичное дерево поиска BST, АВЛ-дерево и Красно-черное дерево (R&B)
Все цифровые устройства на выходе действительно восстанавливают форму и уровень сигнала. Но если речь идет об 1 километре то лучше подумать о другом классе сетевого оборудования. Цепочка свитчей или роутеров усилит лаг и внесет вероятность ошибки.
Операторы мобильной сети как то решают вопросы с длинной дистанцией. Телевидение и прочие отрасли тоже имеют свои коробочные решения. Модет оптика. Может модемы и другие физические кабели. Может радио-ретрансляторы. Да много чего есть.
rav_pr, ты ответил очевидным и бесполезным ответом. Я тоже знаю назначение hashcat. Я не понимаю какие исходные данные из veracrypt ты подашь на вход к hashcat чтобы получить полезный эффект.
Я вообще не понимаю как ты сюда втащил hashcat. У него совсем другая задача и исходные данные для него аж никак не подходят для твоего случая. Мне просто интересно.
Спасибо попробую скриптики. Я верстать не умею. И зная свой перфекционизм - я просто засяду
за изучение Inkscape надолго. А мне - только плакаты обновить надо.
Василий Банников, привык работать с Java. Там обычно артефакты более стабильны. Многим уже лет по 10 и более. Такой бешеной скорости коммитов как в JavaScript нету.
Василий Банников, для тех backend что я создавал. Размер артифакта и время загрузки вообще не имело значения. Джобы. Процессы. Они потребляли тысячу крат больше чем просто один артифакт. Поэтому артифактом больше или меньше значения не имело. А вот гарантии к отсуствию ошибок были важнее.
Василий Банников, скорее всего бояться затягивать в веб-приложение зависимости. Смысл в этом есть. Упаковка ресурсов - меньше. И скорость загрузки выше. Но где здесь золотая середина? С какого числа зависимостей уже становитсья выгодно подключить пакет или модуль. Или как оно там называется?
Vasek1209, Windows Vista была неудачной версией. И файловая система NTFS тоже эволюционировала и я знаю как минимум 4.0/5.0/5.1.
Смотри. Твой вопрос - не теоретический а сугубо практический. Все наши рассуждения может просто поломать какой-то частный случай. Но нам надо эти частные случаи просто собрать в такую честную выборку. Чтоб там не было историй из дореволюционных времен и историй с легаси софтом.
Давай запускай тестирование для двух файловых систем и продолжай наблюдение. Я делаю ставку на то что NTFS - это правильный выбор для магнитного диска.
Vasek1209, я предлагаю следующий эксперимент. Разреж 4Тб диск на два по 2Тб.
Один - форматируй в extFat, другой в NTFS. И начинай эксплуатацию. Что там у тебя? Файловая свалка.
Вот пиши активно файлы. Через пол-годика у тебя будет статистика ошибок и проблем.
Есть такая концепция. EAV (entity->attribute->value). Вобщем она предполагает что весь бизнес можно положить всего в 2 таблицы.
Я никогда не любил EAV но здесь мы имеем дело с другим маргинальным случаем. Пожалуй объединение
сходных или однородных таблиц в более крупную - было бы правильным направлением.
Из похожих моделей. Триплеты и квартеты из RDF/SemanticWeb (subject->predicate->object).
Вообще в одну таблицу все пишут.
И квинтеты есть. С иерархией.
Или даже просто документы. Mongo, CouchDb могут быть компромиссом если мы сможем выделить строку которая укажет сразу ключом на таблицу + id row. Композиция этих ключей - ключ документа.
По поводу индексов. Действительно для 50 полей индексы строить нет смысла. Даже оптимизаторы БД часто выбрасывают индекс из плана при таких размерах.
