Размер архива считается как файл архива + размер разархивирова.
С чего бы? Бывают схемы сжатия, где например словарь хранится отдельно от архива, или даже схема данных хранится отдельно от данных, что тоже экономит место.
В теории-то да, можно представить "распаковщик бесконечного размера", но на практике это невозможно, а размер архиватора не всегда важен. Когда данные куда-то передаются, архиватор не всегда передаётся - он может быть передан 1 раз заранее.
Но вот когда те же ощущения нечистой силы у меня возникают при анализе кода на высокоуровневом языке программирования...
Ничего удивительного в этом нет. Во-первых, проекты со временем именно эволюционируют, когда правки вносятся десятки и сотни раз. Во-вторых, различное применение эволюционных подходов при создании кода вполне себе работает, но вот пытаться понять такой код может быть бессмысленным занятием.
Писать инструкции умеют действительно далеко не все, кто их пишет.
Возможно из-за недостатка времени, или потому, что качественных инструкций не видели... И почему-то чаще проблемы есть в русскоязычных инструкциях. Я много раз видел инструкции, где с первой страницы автор ныряет в мельчайшие детали, которые понятны только после N лет работы в узкой области (т.е. только автору), и вообще не нужны пользователю.
В англоязычных инструкциях (возможно, из-за большего количества пользователей в тех проектах, что я видел) обычно хотя бы придерживаются схемы "введение, основная часть, заключение", которая сразу частично вводит читателя в курс дела. В принципе, ничего не мешает писать инструкции на русском языке по той же схеме, однако я даже встречал сопротивление этому.
Resilient File System во многих отношениях лучше, чем NTFS. Например, NTFS поддерживает максимум 256 терабайт хранения, а ReFS предлагает поддержку до 35 петабайт.
Однако у ReFS нет некоторых функций, которые есть в NTFS, включая сжатие системы и поддержку шифрования. В ReFS также отсутствует поддержка дисковых квот и съёмных носителей.
Как будто концентрировать в компании людей с маленькой зарплатой или не способных зайти на hh - хорошая идея. Впрочем, "нормально делай - нормально будет", в среде 1С наверно это более актуально.
Чаще как раз прибегают к помощи устройств, с которых достаточно сложно украсть ключ, и это довольно надёжно. Распространённый пример - банковская карта с чипом.
Человек вряд ли может выполнить в голове вычисления для реализации шифра, который невозможно взломать с использованием компьютера. Самопридуманные же "криптоалгоритмы" небезопасны совсем, хоть их и можно применять в уме.
Ваш метод ближе к электронной подписи, но вместо обычных, общепринятых, надёжных криптоалгоритмов вы предлагаете использовать новый плохо продуманный "криптоалгоритм" (какие-то замены), который не может быть надёжным исходя из криптографической практики и исходя из принципов криптографии. Эта ошибка описывается на первых страницах учебников. Не делайте так. Ознакомьтесь с темой, возьмите что-то проверенное. Иначе вашу защиту взломают.
Настоящие правила точно так же взламываются. Если они не усилены закрытым крючом, как в схеме цифровой подписи.
Считать, что надёжная защита может быть основана лишь на скрытых правилах - глубокое заблуждение, обычно присущее людям, не знакомым с криптографией. Подробнее тут - https://en.m.wikipedia.org/wiki/Security_through_obscurity
Но даже "игрушечные" Вы не угадали. Ведь с компьютером "ну я только одно ж не угадал, ну пропусти меня, пожалуйста!" не сработает.
Угадал процентов на 80 за пару минут, хотя я не спец в таких ребусах. 3 правила из 4х верны, одно даёт верный результат в ~четверти случаев. Будут ещё примеры - можно будет угадать на 100%. Либо сделать несколько неудачных попыток перед удачной, дождавшись в итоге нулей и двоек на чётных местах - у вас же не одна попытка ввода пароля?
Я бы применил более традиционный механизм цифровых подписей, или одноразовые пароли, или пароли, основанные на дате/времени (последний вариант не очень надёжен, а первые два - не для людей).
Очень похоже по двум примерам, что правила следующие:
1) буква на нечётном месте - заменяется на предыдущую букву в другом регистре.
2) буква на чётном месте - на следующую букву.
3) цифра n на нечётном месте - на n*3 mod 10.
4) цифра n на чётном месте - непонятно, то ли на n+2 mod 10, то ли на n*2 mod 10, то ли на n*7 mod 10.
Пароль проще подсмотреть и ввести, чем отпечаток пальцев. Сейчас, когда телефоны используются очень часто и повсюду, сканер отпечатков скорее повышает защиту, по сравнению с паролем.
Выглядит как оксюморон в контексте Domain-Driven Design.
DDD различает и противопоставляет объекты-значения (value objects), которые иммутабельны и не имеют идентичности, и сущности (entity), которые могут быть различными при одинаковых значениях полей, и поэтому имеют идентификаторы.
Насколько я понимаю, record в java - это для объектов-значений. У них не может быть идентификатора (у них нет идентичности: 2 record с одинаковыми полями не могут различаться), и нет проблем с его установкой.
С чего бы? Бывают схемы сжатия, где например словарь хранится отдельно от архива, или даже схема данных хранится отдельно от данных, что тоже экономит место.
В теории-то да, можно представить "распаковщик бесконечного размера", но на практике это невозможно, а размер архиватора не всегда важен. Когда данные куда-то передаются, архиватор не всегда передаётся - он может быть передан 1 раз заранее.
Почему "революционный"? Идея сжатия автокодировщиками (autoencoder) известна давно.
Рыжая тоже похожа)
Ничего удивительного в этом нет. Во-первых, проекты со временем именно эволюционируют, когда правки вносятся десятки и сотни раз. Во-вторых, различное применение эволюционных подходов при создании кода вполне себе работает, но вот пытаться понять такой код может быть бессмысленным занятием.
Или с тёплой (как опцию).Можно подробней? Мне казалось, в разработке ПО от применения agile толку больше, чем от тонн проектной документации.
А ещё бывает, что "15 минут" - это по обычным часам 25 минут, если не 40 минут.
Где-то я видел статью, в которой автор утверждал, что соли почти всегда нужно сыпать 1% от массы блюда. Инженерный подход!
Писать инструкции умеют действительно далеко не все, кто их пишет.
Возможно из-за недостатка времени, или потому, что качественных инструкций не видели... И почему-то чаще проблемы есть в русскоязычных инструкциях. Я много раз видел инструкции, где с первой страницы автор ныряет в мельчайшие детали, которые понятны только после N лет работы в узкой области (т.е. только автору), и вообще не нужны пользователю.
В англоязычных инструкциях (возможно, из-за большего количества пользователей в тех проектах, что я видел) обычно хотя бы придерживаются схемы "введение, основная часть, заключение", которая сразу частично вводит читателя в курс дела. В принципе, ничего не мешает писать инструкции на русском языке по той же схеме, однако я даже встречал сопротивление этому.
Как-то не очень "лучше".
То ли сарказм, то ли треш.
Как будто концентрировать в компании людей с маленькой зарплатой или не способных зайти на hh - хорошая идея. Впрочем, "нормально делай - нормально будет", в среде 1С наверно это более актуально.
Причины этого могут быть различные.
Более того, иногда люди не понимают, что существуют диктофоны...
А тут нет пароля.
Чаще как раз прибегают к помощи устройств, с которых достаточно сложно украсть ключ, и это довольно надёжно. Распространённый пример - банковская карта с чипом.
Человек вряд ли может выполнить в голове вычисления для реализации шифра, который невозможно взломать с использованием компьютера. Самопридуманные же "криптоалгоритмы" небезопасны совсем, хоть их и можно применять в уме.
Есть общепринятая практика (на которую я ссылался уже дважды), согласно которой методы, которые вы предлагаете, слабы перед взломом.
Обычно используют другие методы - https://ru.wikipedia.org/wiki/Аутентификация#Способы_аутентификации
Ваш метод ближе к электронной подписи, но вместо обычных, общепринятых, надёжных криптоалгоритмов вы предлагаете использовать новый плохо продуманный "криптоалгоритм" (какие-то замены), который не может быть надёжным исходя из криптографической практики и исходя из принципов криптографии. Эта ошибка описывается на первых страницах учебников. Не делайте так. Ознакомьтесь с темой, возьмите что-то проверенное. Иначе вашу защиту взломают.
Настоящие правила точно так же взламываются. Если они не усилены закрытым крючом, как в схеме цифровой подписи.
Считать, что надёжная защита может быть основана лишь на скрытых правилах - глубокое заблуждение, обычно присущее людям, не знакомым с криптографией. Подробнее тут - https://en.m.wikipedia.org/wiki/Security_through_obscurity
Угадал процентов на 80 за пару минут, хотя я не спец в таких ребусах. 3 правила из 4х верны, одно даёт верный результат в ~четверти случаев. Будут ещё примеры - можно будет угадать на 100%. Либо сделать несколько неудачных попыток перед удачной, дождавшись в итоге нулей и двоек на чётных местах - у вас же не одна попытка ввода пароля?
У вас тут security through obscurity.
Я бы применил более традиционный механизм цифровых подписей, или одноразовые пароли, или пароли, основанные на дате/времени (последний вариант не очень надёжен, а первые два - не для людей).
Очень похоже по двум примерам, что правила следующие:
1) буква на нечётном месте - заменяется на предыдущую букву в другом регистре.
2) буква на чётном месте - на следующую букву.
3) цифра n на нечётном месте - на n*3 mod 10.
4) цифра n на чётном месте - непонятно,
то ли на n+2 mod 10, то ли на n*2 mod 10, то ли на n*7 mod 10.Вот, только с последним правилом ошибся.
Любой ключ можно подделать, или украсть, или обойти защиту.
Пароль тоже можно воссоздать по фото пароля, и это настолько банально, что вряд ли об этом найдутся статьи.
Непонятно, однако в аннотации статьи какие-то величины измеряются в килопарсеках.
Баланс между удобством и уровнем безопасности.
Отпечаток пальца довольно удобен.
Пароль проще подсмотреть и ввести, чем отпечаток пальцев. Сейчас, когда телефоны используются очень часто и повсюду, сканер отпечатков скорее повышает защиту, по сравнению с паролем.
Выглядит как оксюморон в контексте Domain-Driven Design.
DDD различает и противопоставляет объекты-значения (value objects), которые иммутабельны и не имеют идентичности, и сущности (entity), которые могут быть различными при одинаковых значениях полей, и поэтому имеют идентификаторы.
Насколько я понимаю, record в java - это для объектов-значений. У них не может быть идентификатора (у них нет идентичности: 2 record с одинаковыми полями не могут различаться), и нет проблем с его установкой.