Как стать автором
Обновить
15
6.4
Калимулин Михаил Игоревич @exwill

Vision developer

Отправить сообщение
Да, у меня тоже были такие сомнения. Но они развеялись, когда я получил информацию от коллеги, который работал не на курсах, а в школе
Не надо пользоваться регистрами
Конечно будет. Но не в следующей статье. Тем много
Может случиться так, что когда ваше неравенство нарушится, вы уже утратите способность к 2
Есть два подхода:
1. прочитать и понять
2. заплатить и забыть
Вы за какой?
ИТС Проф 33 816 руб.
ИТС Техно (эконом-вариант, только обновления) 14 280 руб.
В 2.37 раза. Не ровно, вы правы.

У обычной фирмы годами ничего не меняется, кроме номеров версий форматов. Есть набор основных отчетов, которые устаканились и меняются редко. А если и меняются, то сущностные изменения не затрагивают обычные фирмы. Обычные фирмы субсидируют необычные. На больших дистанциях больше, на малых меньше. Типичное обновление — это мы вам добавили новый КБК «приобретение музыкальных инструментов, оборудования и оргтехники за счет средств резервного фонда Президента Российской Федерации» (ну и исправление ошибок, справедливости ради надо добавить)

А вот тут — самое главное. Я собственно и писал для того, чтобы поднять ровно этот вопрос. Вопрос о месте человека в системе ПО-человек. Отдал заботу ПО и забыл — это хорошо? Или не очень? Если даже в таком относительно простом случае, как налоговая отчетность, мы на выходе получаем странные артефакты, то что будет дальше? Может стоит поискать баланс?
Вот и я про доброжелательность. Если есть кнопка, а при нажатии на нее получается «фиг вам!». Это — доброжелательность или издевательство? Если есть веские причины, тогда почему не убрал кнопку? Убери и не будешь ничего нарушать. Статья об этом
Ну это же (гипотетически) закон. Платить должен тот, кто нарушает.
Но если вдуматься, имплементация такого закона приведет к сокращению расходов пользователей, а не к их росту. В описанном мною случае, пользователь заплатил за то, что ему создали ограничения
Так поделите. Жалко вам что ли? IEEE 754 разрешает
Какие это «другие методы»? Вы не могли бы озвучить?
Вы совершенно правы в том, что в конечном счете все упирается в доверие к ПО. А вернее в то, как нам заменить ДОверие на ПОСЛЕверие. Предложенная мной технология стягивает эту проблему в одну точку. Нам надо перед каждым сеансом сверки проверять наше ПО. И я свожу это ПО к абсолютному минимуму, который может быть быстро загружен и быстро проверен. В особо ответственных случаях, визуально. Пример в статье содержит 20 строк кода. Даже если мы добавим туда SHA256, мы все равно не выйдем за пределы 100 строк.

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

Ответ на вопрос: «что было изменено» можно будет найти в бэкапах. В автоматическом режиме, по ссылке на документ. Я продолжаю настаивать на том, что вопрос «было ли что-то изменено» — ключевой. Решив его, вы решите и все остальное. Не решив, не решите ничего.

Ложные срабатывания — это вообще не проблема. При ложном срабатывании пользователь откатится к предыдущему состоянию журнала и просто еще раз сверит документы прошлого сеанса. И то, это будет происходить только в том случае, когда проверяющий один. В большинстве случаев проверяющих будет не менее двух. И только если сам собственник решит не доверять никому этот процесс и будет заниматься сверкой самостоятельно, тогда возможны редкие ложные срабатывания с некритичными последствиями. Не вижу здесь проблемы
Спасибо всем, кто принял участие в обсуждении. Главный результат заключается в том, что предложенная мной схема с блокчейном — работает. Никто не увидел какой-либо явной «дыры». И это — хорошо. Все озвученные претензии можно свести к двум. Первая — с ЭЦП можно сделать все то же самое, но проще. Вторая претензия заключается в том, что я решаю выдуманную мною же проблему. Отвечу по порядку.
Перефразируя поэта, можно сказать, что «дело прочно, когда под ним струится пот». Строгое соответствие между данными учетной системы и реальностью не возникает само собой. Оно всегда есть результат некоего человеческого усилия. При работе с большими объемами данных, мы решаем задачу поиска минимально необходимых усилий для контроля. Чуть больше усилий, и они могут стать неподъемными из-за большого объема данных. Чуть меньше усилий, и контроль потерян. Наша задача — нащупать эту границу. И я утверждаю, что предложенная мной схема с блокчейном, как раз и находит эту границу. 2 минуты человеческих усилий на сеанс контроля — это, по видимому, абсолютный минимум. А что с ЭЦП? Там же можно просто нажать на красивую кнопочку «Подписать» и это будет еще быстрее? Будет. Но это будет уже по другую сторону границы. Там, где контроль уже утерян. У вас есть каналы связи между базой данных и вашим компьютером и между вашим компьютером и защищенным устройством в обе стороны. Просто нажав кнопочку «Подписать» вы полагаетесь на то, что на подпись будет отправлено именно то, что в базе, а также на то, что подпись, которая в результате уйдет в базу — это именно та подпись, что выдало вам защищенное устройство. Может быть и существует схема с ЭЦП, которая дает человеку возможность контролировать эти каналы. Поправьте меня, кто лучше знает. Но пока у меня большое подозрение, что реально надежная схема с ЭЦП потребует от человека не меньше, а больше усилий, чем схема с блокчейном. Чем еще хороша моя схема, так это тем, что канал там один — ручка, бумажка. Контроль над этим каналом со стороны человека абсолютно надежен. И это очевидно даже неспециалисту.
Что касается второй претензии. Каждый раз, когда вы говорите, что проблема надуманна, где-то хлопает в ладоши от радости человек, который проделал операцию 101х110=110х101. Подумайте, быть может это в вас говорит снобизм? Как так?! Меня, такого умного, объегорит какой-то кладовщик?! Ха-ха! Вот только все меняется очень быстро. Мы уже живем в мире, где все знают все (или, по крайней мере, движемся к этому с огромной скоростью). Что такое базы данных и как с ними обращаться уже сейчас доступно каждому со школьного возраста. Особо заинтересованные и мотивированные могут нагуглить известные дыры в популярных системах и способы повышения привилегий. Хороший пример здесь 1С. То, что пароль к базе данных хранится особо не скрывается. Но и дырка по тем или иным причинам тоже не закрывается уже чуть ли не третий десяток лет. Сколько в России и около учетных систем на базе 1С? Ну и, наконец, не стоит забывать, что в любой учетной системе количество людей, которые могут делать в ней все, что хотят всегда строго больше нуля. Традиционный способ решить проблему «человеческого фактора» в такой ситуации — это дублирование и взаимный контроль. Т.е. кто-то должен контролировать человека, который может все. И это — реальная проблема
Проблему соответствия данных учетной системы реальности
Системе для функционирования может быть и не нужен, но кто-то же его знает. И с этим фактом вы ничего не поделаете
Как необязательно? Если кто-то знает админский пароль к СУБД, то он может делать в системе все, что хочет. Разве не так?
В любой учетной системе количество людей, которые могут делать в ней все, что хотят, строго больше 0.
Я не понимаю вашу позицию. Вы считаете, что проблемы нет вообще? Или что проблема есть, но она имеет лучшие решения?
Но не чаше, чем раз в день?
Затем, что 1С так реализовала трехзвенную архитектуру. Платформа для коннекта не запрашивает пароль у пользователя, а использует сохраненный

Не понял. Поясните, пожалуйста

Деталь А поставляется в коробках по 11 штук, деталь Б в коробках по 17 штук. В процессе приемки на склад часть деталей возвращаются поставщику, как бракованные. Деталь А или деталь Б могут запороть при сборке и тогда ее спишут в отходы, а со склада запросят дополнительную деталь. В реальности почти ни у кого нет такого, что количество деталей совпадает. В любом случае не стоит надеяться на то, что кладовщик — дурак. И будет брать те детали, которые легко обнаружить

Информация

В рейтинге
844-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность