Это полностью ОК, когда дистрибьюторы контента хотят отбить свои лицензионные отчисления правообладателям, борятся с конкурентами, создают привлекательный сервис, пишут в абьюзы, и так далее.
И это совсем непорядочно, когда они начинают заодно бороться с "неправильными" пользователями, использовать манипулятивные ярлыки ("воровство") и претендовать на какое-то моральное превосходство.
В конторе логин основан на фамилии пользователя, так что после развода многие заказывают сменить и фамилию и логин.
У реальных объектов обычно не существует такого свойства, которое гарантированно никогда бы не менялось, так что первичный ключ должен использоваться только для идентификации "да, это тот же самый объект".
У меня есть общие вопросы про валидацию на клиенте. Можно ли полностью полагаться на нее и не проверять данные на back end? Если да, то как защититься от пользователей, умеющих пользоваться browser development tools?
Если таки делать второй слой валидации на сервере, то как синхронизировать бизнес-правила между кодом back-end и front-end? Что делать, если две реализации при независимой разработке рассогласовались, и клиентская валидация требует такой формат ввода, который не проходит серверную?
Почему в статье нет ни слова про ChaCha / Salsa? Они прямо сейчас становятся промышленным стандартом и не имеют отношения к АНБ. Вы же изучали предметную область перед началом разработки, значит NASH должен иметь какие-то преимущества по сравнению с ними?
А что будет с этой оптимизацией в программе, которая мечтала запустить по потоку на всех четырех физических ядрах, но вместо этого оказалась запущенной под Ruby, который был собран без поддержки потоков ОС?
1963 год, Станислав Лем, "Сумма технологии". Государство (или другой игрок), действующее по рекомендациям сильного ИИ, получает стратегическое преимущество, даже если никто не понимает логику принятия решений. Игрок, добровольно ограничивающий мощность "своего" ИИ уровнем собственного понимания, попадает в ситуацию игры человека против AlphaGo и проигрывает. Это дилемма заключенного, выход из которой предопределен, — неконтролируемый сильный ИИ будет создан так же неизбежно, как неизбежно было создание атомной бомбы.
Это полностью ОК, когда дистрибьюторы контента хотят отбить свои лицензионные отчисления правообладателям, борятся с конкурентами, создают привлекательный сервис, пишут в абьюзы, и так далее.
И это совсем непорядочно, когда они начинают заодно бороться с "неправильными" пользователями, использовать манипулятивные ярлыки ("воровство") и претендовать на какое-то моральное превосходство.
Да хоть бы даже и умел. Есть ли хоть какие-нибудь статьи кодексов, которые криминализируют персональное потребление нелицензированного контента?
На основании каких положений закона Алексей Голубев объявляет целую страну "ворами" контента? Какой процент дохода Okko отчисляется авторам?
В конторе логин основан на фамилии пользователя, так что после развода многие заказывают сменить и фамилию и логин.
У реальных объектов обычно не существует такого свойства, которое гарантированно никогда бы не менялось, так что первичный ключ должен использоваться только для идентификации "да, это тот же самый объект".
На шаге 2 серьезно предлагается на своем сервере запустить от рута неизвестно чей скрипт из интернета, даже не читая его?
У меня есть общие вопросы про валидацию на клиенте. Можно ли полностью полагаться на нее и не проверять данные на back end? Если да, то как защититься от пользователей, умеющих пользоваться browser development tools?
Если таки делать второй слой валидации на сервере, то как синхронизировать бизнес-правила между кодом back-end и front-end? Что делать, если две реализации при независимой разработке рассогласовались, и клиентская валидация требует такой формат ввода, который не проходит серверную?
Кэш без контроля размера это просто еще один способ организовать утечку памяти.
Для ключа нужно еще примеров. Лучше пару миллионов.
"PaSSWoRD", давайте другой пример, этот не годится.
Почему в статье нет ни слова про ChaCha / Salsa? Они прямо сейчас становятся промышленным стандартом и не имеют отношения к АНБ. Вы же изучали предметную область перед началом разработки, значит NASH должен иметь какие-то преимущества по сравнению с ними?
А что будет с этой оптимизацией в программе, которая мечтала запустить по потоку на всех четырех физических ядрах, но вместо этого оказалась запущенной под Ruby, который был собран без поддержки потоков ОС?
1963 год, Станислав Лем, "Сумма технологии". Государство (или другой игрок), действующее по рекомендациям сильного ИИ, получает стратегическое преимущество, даже если никто не понимает логику принятия решений. Игрок, добровольно ограничивающий мощность "своего" ИИ уровнем собственного понимания, попадает в ситуацию игры человека против AlphaGo и проигрывает. Это дилемма заключенного, выход из которой предопределен, — неконтролируемый сильный ИИ будет создан так же неизбежно, как неизбежно было создание атомной бомбы.