Все остальное разумнее свалить на парольный менеджер, который сгенерирует двадцать случайных символов, сам их запомнит и избавит вас от необходимости вообще их читать глазами.
Всё это ломается о простую житейскую истину. Которая заключается в том, что на одних сайтах пароль непременно должен содержать маленькие и большие буквы, цифру и какую-нибудь крюкозябру, на других большие буквы и крюкозябры запрещены, а третьи вообще делают всё, чтобы пользователь неприменно ввёл пароль руками, а не копипастой из менеджера пароля.
И да, все сложные пароли с обязательным требованием их регулярной замены без повторов неизбежно кончают свой жизненный путь, будучи записанными на маленькой жёлтенькой бумажке, приклеенной к монитору. Хорошо если дома, а не в офисе.
Есть встроенные в язык каналы и библиотечные примитивы синхронизации, типа мьютексов. Но использовать и то и другое - задача программиста.
Идея, которую притащил Пайк, заключается в том, что запуск гороутинки (так в Go называются легковесные потоки) - вещь недорогая, и не надо их экономить. Например, как мы экономим потоки в программах на C/C++, потому что тамошние потоки - это реальные потоки операционной системы.
Но всё-таки надо понимать, что у каждой гороутинки есть хотя бы 2K стека, и если их запустить миллион, то 2G уйдут только под стеки. Поэтому не надо относиться к идеям Пайка с фанатизмом :)
Феррит легко намагнитить в + и - до насыщения, но трудно размагнитить в 0. Поэтому трит представлялся двумя ферритовыми элементами (двумя битами) и было запрещённое состояние. Что, в принципе, не очень.
В кремнии я бы присмотрелся к дифференциальным каскадам. При двухполярном питании работать с +V, -V и 0 довольно удобно.
Перепад в 1 вольт на бит - это что-то из области современной микроэлектроники. В те времена это звучало бы, как шутка, и пару-тройку десятилетий спустя тоже. Как и нулевое потребление в режиме покоя.
Просто в качестве упражнения: возьмите любую понравившуюся открытую программу, поручите ИИ сделать её «чистую» реализацию (clean-room), выпустите её под другой лицензией
И будете всегда в позиции догоняющего.
Неплохая стратегия для CD-ejector-а, но такая себе для продукта посложнее.
Мне понадобилась неделя, чтобы выучить язык с нуля и начать на нём активно писать какой-то код, и полгода, чтобы научиться писать на Go идеоматический код. А так всё скорее по-сишному получалось.
Но при этом, с Си за плечами, идея о том, что слайсы могут использовать перекрывающуюся память вопросов не вызывала. Это очень по-сишному :)
Суть патента - в изобретении backing store - невидимой памяти, куда приложения рисуют, не задумываясь о том, что их окошко может быть частично или полностью перекрыто другими, а потом графическая система собирает из этих отрисованных, но невидимых прямоугольников финальную картинку, с учётом перекрытий.
AT&T активно использована этот патент против разработчиков X Windows System, но прямо вот до суда не дошло.
Так что да, этот патент является хрестоматийным примером патентного троллинга.
Не то, что-то с таким подходом. Не доложно быть так. Не может нормальная технология лажать в методе из одной строки. Почему для обновления одного булевого поля вообще нужно знать про существование @DynamicUpdate? Почему простейшая операция зависит от таких нюансов? Почему, чтобы система работала надёжно, я должен помнить десятки подобных особенностей?
Всё это ломается о простую житейскую истину. Которая заключается в том, что на одних сайтах пароль непременно должен содержать маленькие и большие буквы, цифру и какую-нибудь крюкозябру, на других большие буквы и крюкозябры запрещены, а третьи вообще делают всё, чтобы пользователь неприменно ввёл пароль руками, а не копипастой из менеджера пароля.
И да, все сложные пароли с обязательным требованием их регулярной замены без повторов неизбежно кончают свой жизненный путь, будучи записанными на маленькой жёлтенькой бумажке, приклеенной к монитору. Хорошо если дома, а не в офисе.
А куда палец-то суют или морду лица? В какое-то дополнительное хитрое устройство, или в штатный сканер/камеру собственного гаджета?
Не думали для звонков сделать прямое p2p соединение с NAT traversal?
Лучше бы мультикаст
Раз в 5 секунд - много, если в локалке много клиентов
Не думали про DNS-SD вместо самодельного discovery?
Т.е., всё шифрование основано на алгоритмах, придуманых Бернштейном. Стрёмный он, этот Бернштейн…
Кажется, у Шнайера рассказывается, что DHE может быть обобщён на несколько участников.
Ничего не понятно, но очень интересно
email невозможно провалидировать регуляркой, там синтаксис не регулярный, а контекстно-свободный.
В Go это попало из его предшественников, языков Alef и Limbo
В древнем но весьма популярном в узких кругах Erlang тоже есть синтаксичаская поддержка дешевых потоков.
Так что нет, увы, этим Go не уникален.
Ничего оно там само не синхронизируется.
Есть встроенные в язык каналы и библиотечные примитивы синхронизации, типа мьютексов. Но использовать и то и другое - задача программиста.
Идея, которую притащил Пайк, заключается в том, что запуск гороутинки (так в Go называются легковесные потоки) - вещь недорогая, и не надо их экономить. Например, как мы экономим потоки в программах на C/C++, потому что тамошние потоки - это реальные потоки операционной системы.
Но всё-таки надо понимать, что у каждой гороутинки есть хотя бы 2K стека, и если их запустить миллион, то 2G уйдут только под стеки. Поэтому не надо относиться к идеям Пайка с фанатизмом :)
Вопрос, наверное, к автору публикации :)
А правильный, это какой?
Что каждая гороутинка по-своему уникальна? :)
в том, что они легковесные
в том, что у них нет видимого пользователю идентификатора
в том, что для них не предусмотрен thread local storage
в том, что Пайк призывает особо не экономить их количество
в том, что гошники исхитрились сделать вытесняющую многопоточность в user space
в том, что AT&T пыталась сделать N:M многопоточность в своём UNIX и не осилила, а гошники осилили
в том, что Rust-овцы тоже грозились сделать лёгкие потоки, но не смогли
в том, что их запуск встроен в синтаксис языка
в том, что их название созвучно названию языка
…
Интересно, какой из этих ответов ожидаете вы? ;)
Вот и выросло поколение, не заставшее других кодировок, кроме UTF-8…
Феррит легко намагнитить в + и - до насыщения, но трудно размагнитить в 0. Поэтому трит представлялся двумя ферритовыми элементами (двумя битами) и было запрещённое состояние. Что, в принципе, не очень.
В кремнии я бы присмотрелся к дифференциальным каскадам. При двухполярном питании работать с +V, -V и 0 довольно удобно.
Перепад в 1 вольт на бит - это что-то из области современной микроэлектроники. В те времена это звучало бы, как шутка, и пару-тройку десятилетий спустя тоже. Как и нулевое потребление в режиме покоя.
И будете всегда в позиции догоняющего.
Неплохая стратегия для CD-ejector-а, но такая себе для продукта посложнее.
Может потому и помер? ;)
Эээ. Но слово “дискотека” появилось в эпоху виниловых пластинок…
Мне понадобилась неделя, чтобы выучить язык с нуля и начать на нём активно писать какой-то код, и полгода, чтобы научиться писать на Go идеоматический код. А так всё скорее по-сишному получалось.
Но при этом, с Си за плечами, идея о том, что слайсы могут использовать перекрывающуюся память вопросов не вызывала. Это очень по-сишному :)
Суть патента - в изобретении backing store - невидимой памяти, куда приложения рисуют, не задумываясь о том, что их окошко может быть частично или полностью перекрыто другими, а потом графическая система собирает из этих отрисованных, но невидимых прямоугольников финальную картинку, с учётом перекрытий.
AT&T активно использована этот патент против разработчиков X Windows System, но прямо вот до суда не дошло.
Так что да, этот патент является хрестоматийным примером патентного троллинга.
Тут не лишне бы упомянуть, что Plan 9 растащили по цитатам по другим ОС
Linux namespaces, bind mount, unionfs, все эти /proc и /sys - это всё оттуда.
Это называется Leaky abstraction. https://en.wikipedia.org/wiki/Leaky_abstraction
Увы, из удобных высокоуровневых абстракций иногда подтекают их низкоуровневые детали реализации.
А если из ИИ подтечёт? :)