Да, при таком подходе наверное покатит. Правда, насколько я понимаю, чтобы незнание пароля считалось нарушением трудовой дисциплины нужно, чтобы требование знание пароля наизусть было зафиксировано в трудовых обязанностях работника. Что вроде реализуемо.
С другой стороны все это — тонна бюрократии, отчетности и времени непонятно для чего. Проще уж реально внедрить какие-нибудь rsa токены.
Мало кто желает в совокупности рассмотреть проблему безопасности.
Истинно так.
Все эти регулярные смены паролей и абсурдные требования подчас напоминают крепостные ворота в деревянном заборчике в метр высотой. Эдакая непоколебимая уверенность в том, что злоумышленник будет ломиться исключительно в самую защищенную точку системы.
По закону нельзя просто так взять и уменьшить/не выплатить премию. Впрочем увеличить/выплатить просто так тоже нельзя. Согласно 129 ст. ТК РФ премия — это часть заработной платы.
Выплата премий регламентируется либо трудовым договором, либо положением о премировании. И вот в таком документе должно быть отражено за какие заслуги премия платится и в каких количествах. Соответственно, чтобы порезать человеку премию на том основании, что он не помнит свой пароль, нужно как-то фиксировать это требование. И вот как такое требование нормально закрепить в том же положении о премировании или трудовом договоре я хз. Т.е. зафиксировать-то просто, но вот зафиксировать так чтобы суд, в случае тяжбы, не признал такое требование ничтожным — это уже задачка сложнее.
С другой стороны работник, скорее всего, не будет париться и идти в суд (и ждать пару лет решения, ага) чтобы ему выплатили премию.
Мне как-то попалась система, которая требовала пароль с буквами в обоих регистрах, цифрами и спецсимволами длинной от 7 и до 10 символов. В тот раз подход, подобный вашему, впервые дал для меня сбой, так как пароля удовлетворяющего таким требованиям у меня не было.
Мне несколько раз попадались сайты, которые на попытку восстановить пароль ругались, что мой новый пароль отличается от старого всего одним символом. Вот такие вот сумрачные гении попадаются.
Про «великое чудо» — вы меня с кем-то путаете :), я такого не писал. Я лишь указал на статистическую незначимость вашего рассуждения про античных философов.
Насчет лопарей, у вас уже значимый аргумент, тут правда еще можно сыграть на не репрезентативности выборки. Впрочем, в том же источнике чуть ниже дано еще более сильное утверждение — среди всего РСФСР умершие в возрасте 70 лет и старше составили 8% от всех умерших в 1925 году. Вот это уже перекрыть сложно.
Если бы шестидесятилетний старик считался (цитирую) «великим чудом», девяностолетних помнили бы в том числе, если не в первую очередь, за долголетие.
Люди прожившие больше 110 лет даже сейчас невероятная редкость, но они есть. Много вы таких людей поименно знаете? Без гугла пожалуйста.
Поэтому статистически значимых величин вам в этой дискуссии приведут вряд ли
Ну раз значимых данных за данный период у нас нет, то зачем же к нему апеллировать? Если вы хотите кому-то что-то доказать, то обращайтесь к фактам, их, в отличие от домыслов, сложно опровергнуть.
А можно подробнее? А то я что-то такое уже не в первый раз слышу, но реальных примеров за 6 лет не наблюдал. Да и быстрое гугление не выдает чего-то вразумительного.
Практически любой документ со сложной структурой, который есть необходимость править руками. Например конфиги или дескрипторы развертывания. За счет наличия XSD схемы XML легко проверить на валидность. За счет той же XSD во многих IDE работает автодополнение. По XSD можно даже автоматом сгенерить объектную модель.
Если требуется обработка больших объемов XML, то на помощь приходит XSLT и XQuery.
А еще в json нет неймспейсов.
Если же работать с документом как с DOM деревом или мапить его на объекты, то разницы между форматами по сути и нет — все равно всё спрятано за библиотеками.
А насчет HTML:
А вы взгляните на reactjs — там есть virtual dom, который как раз представляет html в виде json. Просто сравните:
<p class="lead">
<span>A JavaScript library for building user interfaces </span>
<a href="http://facebook.github.io/react/">React</a>
</p>
и
{
tag: 'p',
attrs: {className: {'lead': true}},
children: [
{
tag: 'span',
children: 'A JavaScript library for building user interfaces '
},
{
tag: 'a',
attrs: {href: 'http://facebook.github.io/react/'},
children: 'React'
}
]
}
Да, в Java обратную совместимость не нарушали никогда (если конечно не завязывать на недокументированный функционал, типа способа работы String.intern или Unsafe). Поэтому мажорная версия там единичка.
Хорошо это или плохо — спорный вопрос. С одной стороны круто, что код написанный в бородатые времена на Java 1.0 будет работать до сих пор.
А с другой стороны стороны в Java из-за этого висит куча классов с невменяемым API. Например я для всех своих проектов тяну сторонние библиотеки для логирования и парсинга XML, хотя формально все это есть в стандартной библиотеке.
И опять таки, все это относится исключительно к JavaSE. В JavaEE обратную совместимость нарушается, но что-то я не видел чтобы кто-то жаловался что EJB 2.0 не поддерживаются в Java EE 7.
Что-то я вас не пойму.
Весь профит генной модификации как раз в том, что можно выбрать какие характеристики привить. И вот тут можно привить исключительно бесплодие, а можно привить всё кроме неё, создав нечто вроде лошака, но уже способного к размножению. Тут уже всё на совести «производителя».
Ну вот прям одновременно конечно не меняю один файл несколькими программами — ОС не даст. А вот с интервалом в несколько секунд модифицировать файл двумя разными программами — постоянный кейс (git+IDE).
У меня есть выкачанный проект на java.
К директории должен иметь доступ на запись гит (он обновляет проект из репозитория, а значит создает/изменяет файлы).
Должна иметь доступ на запись IDE (ну тут все очевидно).
Должен иметь на доступ текстовой редактор (у меня в проекте есть данные для тестов в огромных json/xml файлах, их редактировать в IDE — это боль, страдание, full gc и out of memmory).
Еще в проект могут быть какие-нибудь картинки, которые тоже нужно иногда редактировать.
Зачастую есть еще всякие вспомогательные тулы (типа генераторов кода) которым тоже неплохо бы иметь доступ на запись в директорию проекта.
Ну и уже молчу про всякие компиляторы, билд системы, статические анализаторы и т.д. Они конечно могут писать каждый в свою директорию, но это неудобно как-то.
Зато безопасно, да. Мифический вирус не удалит мне мой проект и мне не придется тратить 5 минут на то чтобы выкачать его из гит по новой.
Не, где-то такие ОС наверное нужны, но я бы предпочел остаться на унылых и небезопасных винде и линуксе.
Ну хорошо, пункт 1 выпадает из процесса редактирования документа на флешке. Допустим.
Но что насчёт совместной работы нескольких программ над одним набором файлов (пример с IDE, компилятором и т.д.)?
Вообще для программ свойственно работать над общим набором файлов.
Что касается вопроса баланса удобства и защиты данных, то я не был бы так категоричен. Да, есть системы, в которых защита данных — это невероятно важный параметр. Вот только это не Компьютеры рядовых пользователей. Для обычного человека вопрос удобства невероятно важен. Иначе не было бы паролей 123, не было бы менеджеров паролей, у всех бы в браузере был бы отключён js и т.д.
В таком случае, если мне понадобится отредактировать документ на флешке, то мне понадобится:
1)Скопировать документ в папку с word.
2)Открыть, отредактировать и сохранить его word'ом.
3)Скопировать назад на флешку.
Как-то неудобно получается.
Так же непонятно что делать с файлами, с которыми работают сразу несколько программ. Например к исходникам должны иметь доступ IDE, компилятор, git, билд система, простой текстовый редактор, статический анализатор, etc. В какую папку мне копировать исходники?
С другой стороны все это — тонна бюрократии, отчетности и времени непонятно для чего. Проще уж реально внедрить какие-нибудь rsa токены.
Все эти регулярные смены паролей и абсурдные требования подчас напоминают крепостные ворота в деревянном заборчике в метр высотой. Эдакая непоколебимая уверенность в том, что злоумышленник будет ломиться исключительно в самую защищенную точку системы.
Выплата премий регламентируется либо трудовым договором, либо положением о премировании. И вот в таком документе должно быть отражено за какие заслуги премия платится и в каких количествах. Соответственно, чтобы порезать человеку премию на том основании, что он не помнит свой пароль, нужно как-то фиксировать это требование. И вот как такое требование нормально закрепить в том же положении о премировании или трудовом договоре я хз. Т.е. зафиксировать-то просто, но вот зафиксировать так чтобы суд, в случае тяжбы, не признал такое требование ничтожным — это уже задачка сложнее.
С другой стороны работник, скорее всего, не будет париться и идти в суд (и ждать пару лет решения, ага) чтобы ему выплатили премию.
А почему работника должны волновать риски работодателя?
Насчет лопарей, у вас уже значимый аргумент, тут правда еще можно сыграть на не репрезентативности выборки. Впрочем, в том же источнике чуть ниже дано еще более сильное утверждение — среди всего РСФСР умершие в возрасте 70 лет и старше составили 8% от всех умерших в 1925 году. Вот это уже перекрыть сложно.
Люди прожившие больше 110 лет даже сейчас невероятная редкость, но они есть. Много вы таких людей поименно знаете? Без гугла пожалуйста.
Ну раз значимых данных за данный период у нас нет, то зачем же к нему апеллировать? Если вы хотите кому-то что-то доказать, то обращайтесь к фактам, их, в отличие от домыслов, сложно опровергнуть.
Я могу так же привести 3 примера людей, которые жили 116 лет, но из этого не следует, что это что-то обычное.
Если требуется обработка больших объемов XML, то на помощь приходит XSLT и XQuery.
А еще в json нет неймспейсов.
Если же работать с документом как с DOM деревом или мапить его на объекты, то разницы между форматами по сути и нет — все равно всё спрятано за библиотеками.
А насчет HTML:
А вы взгляните на reactjs — там есть virtual dom, который как раз представляет html в виде json. Просто сравните:
и
Хорошо это или плохо — спорный вопрос. С одной стороны круто, что код написанный в бородатые времена на Java 1.0 будет работать до сих пор.
А с другой стороны стороны в Java из-за этого висит куча классов с невменяемым API. Например я для всех своих проектов тяну сторонние библиотеки для логирования и парсинга XML, хотя формально все это есть в стандартной библиотеке.
И опять таки, все это относится исключительно к JavaSE. В JavaEE обратную совместимость нарушается, но что-то я не видел чтобы кто-то жаловался что EJB 2.0 не поддерживаются в Java EE 7.
Весь профит генной модификации как раз в том, что можно выбрать какие характеристики привить. И вот тут можно привить исключительно бесплодие, а можно привить всё кроме неё, создав нечто вроде лошака, но уже способного к размножению. Тут уже всё на совести «производителя».
Вообще многие гибриды не способны к размножению.
У меня есть выкачанный проект на java.
К директории должен иметь доступ на запись гит (он обновляет проект из репозитория, а значит создает/изменяет файлы).
Должна иметь доступ на запись IDE (ну тут все очевидно).
Должен иметь на доступ текстовой редактор (у меня в проекте есть данные для тестов в огромных json/xml файлах, их редактировать в IDE — это боль, страдание, full gc и out of memmory).
Еще в проект могут быть какие-нибудь картинки, которые тоже нужно иногда редактировать.
Зачастую есть еще всякие вспомогательные тулы (типа генераторов кода) которым тоже неплохо бы иметь доступ на запись в директорию проекта.
Ну и уже молчу про всякие компиляторы, билд системы, статические анализаторы и т.д. Они конечно могут писать каждый в свою директорию, но это неудобно как-то.
Зато безопасно, да. Мифический вирус не удалит мне мой проект и мне не придется тратить 5 минут на то чтобы выкачать его из гит по новой.
Не, где-то такие ОС наверное нужны, но я бы предпочел остаться на унылых и небезопасных винде и линуксе.
Но что насчёт совместной работы нескольких программ над одним набором файлов (пример с IDE, компилятором и т.д.)?
Вообще для программ свойственно работать над общим набором файлов.
Что касается вопроса баланса удобства и защиты данных, то я не был бы так категоричен. Да, есть системы, в которых защита данных — это невероятно важный параметр. Вот только это не Компьютеры рядовых пользователей. Для обычного человека вопрос удобства невероятно важен. Иначе не было бы паролей 123, не было бы менеджеров паролей, у всех бы в браузере был бы отключён js и т.д.
1)Скопировать документ в папку с word.
2)Открыть, отредактировать и сохранить его word'ом.
3)Скопировать назад на флешку.
Как-то неудобно получается.
Так же непонятно что делать с файлами, с которыми работают сразу несколько программ. Например к исходникам должны иметь доступ IDE, компилятор, git, билд система, простой текстовый редактор, статический анализатор, etc. В какую папку мне копировать исходники?