Скажите, пожалуйста, вам не кажется, что полсотни комментариев // PVS-Studio: в одной статье — это как-то слегка перебор? Это у вас KPI для технических писателей такое?
Да, нужно сначала сгенерировать пароль, а потом придумать к нему какую-нибудь ассоциацию. Придумать ассоциацию к нескольким случайным словам проще, чем к паролю из случайных символов с той же энтропией.
... и это в той же степени криптостойкий пароль.
Увы, но нет. Пространство поиска среди осмысленных сочетаний качественно меньше, чем пространство поиска среди сочетаний случайных слов. Строгих пруфов не приведу, но если бы это было не так, люди бы с трудом распознавали речь на слух и нейросетевые языковые модели работали бы намного хуже.
К тому же, давайте предположим, что атакующему в деталях известна процедура генерации пароля. Если атакующий знает, что вы честно используете Diceware, это никак особенно не поможет ускорить перебор пароля. Если атакующий знает, что вы выбираете в качестве пароля пару осмысленных слов и добиваете их цифрами и специальными знаками, он получает большое преимущество.
... но он состоит из реальных слов, которые попадают под dictionary attack.
Если ваш пароль состоит из достаточного количества случайных словарных слов, уже неважно, что каждое по-отдельности — словарное.
... это больше на тему юмора и концепции, чем про реальное применение.
Для реального применения более чем годится и рекомендуется EFF. По ссылке написано: бросьте кость несколько раз, составьте броски в число, выберите по этому числу слово из большого словаря, повторите так шесть раз. Вот, например, онлайн-генератор, который ровно это и делает: Diceware. А ещё генерация случайных словарных фраз есть в менеджерах паролей (как минимум, в KeepassXC и Bitwarden).
Думаю, вы зря так быстро отбросили DVI: он простой, как палка и верёвка, и работает на любой разумной пискельной частоте.
Выяснилось, что [HDMI —] последовательный, а это значит, частота вывода пикселей составляет порядка 25 МГц, а после сериалайзера — все 250 МГц.
Это совершенно не проблема. Если верить даташиту на это семейство ПЛИС, OSERDES2 (сериализующий выходной дифференциальный буфер) на чипах спидгрейда -2 (такой чип на картинке) выдаёт 500-1080 мегабит/с в зависимости от источника клока. Если не все OSERDES2 заняты под DDR-память, на них можно было бы организовать видеовыход.
К тому же этот интерфейс требует модуль TMDS [...]
У этого семейства заявлена поддержка TMDS, но есть ограничения по банкам и питающим напряжениям. Для TMDS-источника даже внешних резисторов не надо, они ставятся на стороне приёмника.
Внутри данного интерфейса, как и у HDMI, есть LVDS-линии [...]
У вас тут фактическая ошибка. LVDS — это не общий термин для вообще любого дифференциального интерфейса, а отдельный стандарт. У LVDS и TMDS отличаются уровни напряжений и по-разному делается согласование приёмника с источником. Поэтому ни в DVI, ни в HDMI нет LVDS-линий.
Для честного голосования добавьте вариант: «Ничего не предпринимать». Появится ваш василиск — будем решать проблему.
И именно в этом видится настоящая угроза человечеству.
У человечества есть тысяча угроз пострашнее этой унылой псевдофилософской концепции. Вся значимость которой, к тому же, раздута из единственного поста Юдковского и прикольного названия.
Модуль AES сейчас стоит даже в копеечных старших STM32
Так AES — симметричный блочный шифр. На его основе легко сделать «банальный MAC», но ускорить асимметричные шифры такой аппаратный модуль ни капли не поможет.
Подобное использование директив условной компиляции крайне усложняет чтение кода. Нарушается вложенность, и приходится с усилием пытаться понять, что написано ...
Вот только в приведённых примерах нет никакого нарушения вложенности.
Я бы сделал здесь две разные реализации функции: [...]. Суть длиннее, но читать код намного приятнее.
Имхо, вкусовщина. Лично мне читать стало менее приятно, потому что стало сложнее понять, чем же именно эти функции различаются — нужно сравнить не только смысловые строчки, но и сигнатуры функций, чтобы убедиться, что эти сигнатуры идентичны в обоих вариантах (точно ли они обе const noexcept, например). Чем меньше строк под #ifdef, тем лучше.
и за одну ночь к нему прилипает примерно 300-500тыс рублей процентами
По моим грубым прикидкам для этого нужно положить на депозит примерно 1,5 млрд рублей. Не каждая компания может похвастаться подобным дневным оборотом.
Но работать в Redmine - это треш и угар, конечно, по сравнению с современными системами.
А что не так с редмайном? Я помню его как довольно приятный багтрекер. Судя по официальному сайту, проект до сих пор живой (в декабре был последний стабильный релиз). Чем он не современный-то?
Ну на кой хрен вы в билете спрашиваете "доказательство теоремы Вейерштрасса" или "второй признак сходимости"?
Потому что студенты должны знать общепринятые терминологию, обозначения и имена, это часть профессиональной квалификации.
И ещё потому, что развёрнутый вопрос содержит в себе половину ответа. Если студент забыл, какой из признаков сходимости второй, пусть напишет все, какие знает.
Когда кэш заполнен и необходимо сохранить новый результат, наименее использованный результат вытесняется из кэша, чтобы освободить место для нового. Это называется стратегией наименее использованного результата (LRU).
Какой-то супернеудачный перевод. Ну не придумывайте вы своих терминов: во всём гугле нет ни одного результата по запросу "стратегия наименее использованного результата" (в кавычках).
На что получаю ответ, что он, опытный мастер, наблюдая за моими руками, никакой осмысленности в моем черновом коде не видит. [...] Человек из Яндекса не может прочесть код с оператором “запятая”?
Я не опытный мастер из "Яндекса", но, кажется, догадываюсь, в чём дело. Человек не "не может" прочитать код, он не хочет его читать, потому что он выглядит как нагромождение строк и не воспринимается взглядом, его нужно декодировать. Этого достаточно для отказа.
Предположу, что собеседующий хотел увидеть декомпозированное на несколько функций решение, как-то так:
ListNode* mergeAndSortInplace(ListNode* a, ListNode* b) {
a = sortInplace(a);
b = sortInplace(b);
return mergeSortedInplace(a, b);
}
ListNode* mergeSortedInplace(ListNode* a, ListNode* b) {
// Тут делаем в один проход слияние двух отсортированных
// списков и возвращаем голову результата.
}
ListNode* sortInplace(ListNode* list) {
// Тут делаем сортировку (быструю или, если не хватает
// времени, пузырьковую) и возращаем голову результата.
}
В итоге, похоже, нам остаётся один вариант: использовать функции - расширения.
Или использовать операцию умножения, которая здесь очень подходит по смыслу. Например, если понимать обозначение «кг» как синоним величины «1 кг», а «м³» — как синоним «1 м³» (то есть «1 м ⋅ 1 м ⋅ 1 м»), то можно весьма вольно обращаться с числами и единицами измерения:
... получить правильный результат можно и через последовательность вызовов OrderBy().OrderBy(), нужно только поменять вызовы местами.
Чтобы это работало, в реализациии OrderBy должна использоваться устойчивая сортировка. В то же время, SQL-оператор ORDER BY не гарантирует устойчивость. Поэтому я бы не поручился за то, что все провайдеры LINQ-to-SQL правильно обработают это ваше .OrderBy().OrderBy().
Неужели вообще кто-то так делает? Откуда возникла идея написать статью на тему «сравним в подробностях два способа сделать сортировку: очевидно правильный, быстрый и предсказуемый и очевидно неправильный, медленный и с граблями»?
Например, для того, чтобы заранее определиться с именами классов и файлов и поменьше переименовывать потом в процессе. Переименовывать файлы при рефакторинге неудобно, потому что затрагивает систему контроля версий. Ещё имена имеют тенденцию цепляться друг за друга, поэтому может получиться, что из-за одного непродуманного названия нужно будет переименовать дюжину файлов и кучу переменных внутри них.
Почему мешаться-то?
Потому что агрится на псевдокод и отвлекает внимание инспекциями и подчёркиваниями. Если же лень покидать IDE, я частенько открываю многострочный комментарий прямо по месту и в нём уже прикидываю алгоритм, а потом переношу в код.
Если класс настолько велик, что его не получается удержать в голове - это попахивает проблемами проектирования, не?
Имхо, как раз на этапе проектирования черновик полезнее всего. Допустим, хотите вы добавить какую-то новую функциональность: открываете чистую вкладку в блокноте, пишете пример-другой кода так, как если бы то, что вы хотите спроектировать уже было готово, рядом прикидываете, какие классы нужны, в какие неймспейсы их поместить, что должно быть внутри этих классов, долго выбираете всему этому как можно более логичные и последовательные имена, перераспределяете области ответственности, смотрите, что можно декомпозировать и переиспользовать.
Для всего этого IDE не нужна и будет только мешаться.
В своей повседневной работе никто не пишет черновики кода на доске или в «Блокноте».
А я вот пишу, на бумаге и в Notepad++, псевдокодом, с сокращениями. Так ведь удобнее думать, нет? Понять, что от чего должно зависеть, прикинуть, какие у класса должны быть методы и как вообще лучше разбить задачу на классы.
Сколько лет вижу в статьях этот аргумент, столько лет понять не могу: люди, как вы вообще можете думать в IDE, без псевдокода, схем и рисунков?
Как насчёт такого?
Или же, если проверяемый проект есть на гитхабе, рядом с фрагментом кода давать прямую ссылку на релевантную строчку в коде.
Скажите, пожалуйста, вам не кажется, что полсотни комментариев
// PVS-Studio:в одной статье — это как-то слегка перебор? Это у вас KPI для технических писателей такое?Да, нужно сначала сгенерировать пароль, а потом придумать к нему какую-нибудь ассоциацию. Придумать ассоциацию к нескольким случайным словам проще, чем к паролю из случайных символов с той же энтропией.
Увы, но нет. Пространство поиска среди осмысленных сочетаний качественно меньше, чем пространство поиска среди сочетаний случайных слов. Строгих пруфов не приведу, но если бы это было не так, люди бы с трудом распознавали речь на слух и нейросетевые языковые модели работали бы намного хуже.
К тому же, давайте предположим, что атакующему в деталях известна процедура генерации пароля. Если атакующий знает, что вы честно используете Diceware, это никак особенно не поможет ускорить перебор пароля. Если атакующий знает, что вы выбираете в качестве пароля пару осмысленных слов и добиваете их цифрами и специальными знаками, он получает большое преимущество.
Если ваш пароль состоит из достаточного количества случайных словарных слов, уже неважно, что каждое по-отдельности — словарное.
Для реального применения более чем годится и рекомендуется EFF. По ссылке написано: бросьте кость несколько раз, составьте броски в число, выберите по этому числу слово из большого словаря, повторите так шесть раз. Вот, например, онлайн-генератор, который ровно это и делает: Diceware. А ещё генерация случайных словарных фраз есть в менеджерах паролей (как минимум, в KeepassXC и Bitwarden).
Думаю, вы зря так быстро отбросили DVI: он простой, как палка и верёвка, и работает на любой разумной пискельной частоте.
Это совершенно не проблема. Если верить даташиту на это семейство ПЛИС, OSERDES2 (сериализующий выходной дифференциальный буфер) на чипах спидгрейда -2 (такой чип на картинке) выдаёт 500-1080 мегабит/с в зависимости от источника клока. Если не все OSERDES2 заняты под DDR-память, на них можно было бы организовать видеовыход.
Цифры я смотрел тут: https://docs.xilinx.com/v/u/en-US/ds162, стр. 18.
У этого семейства заявлена поддержка TMDS, но есть ограничения по банкам и питающим напряжениям. Для TMDS-источника даже внешних резисторов не надо, они ставятся на стороне приёмника.
Про схему согласования есть в другом даташите: https://docs.xilinx.com/v/u/en-US/ug381, стр. 36.
У вас тут фактическая ошибка. LVDS — это не общий термин для вообще любого дифференциального интерфейса, а отдельный стандарт. У LVDS и TMDS отличаются уровни напряжений и по-разному делается согласование приёмника с источником. Поэтому ни в DVI, ни в HDMI нет LVDS-линий.
Для честного голосования добавьте вариант: «Ничего не предпринимать». Появится ваш василиск — будем решать проблему.
У человечества есть тысяча угроз пострашнее этой унылой псевдофилософской концепции. Вся значимость которой, к тому же, раздута из единственного поста Юдковского и прикольного названия.
Так AES — симметричный блочный шифр. На его основе легко сделать «банальный MAC», но ускорить асимметричные шифры такой аппаратный модуль ни капли не поможет.
Вот только в приведённых примерах нет никакого нарушения вложенности.
Имхо, вкусовщина. Лично мне читать стало менее приятно, потому что стало сложнее понять, чем же именно эти функции различаются — нужно сравнить не только смысловые строчки, но и сигнатуры функций, чтобы убедиться, что эти сигнатуры идентичны в обоих вариантах (точно ли они обе
const noexcept, например). Чем меньше строк под#ifdef, тем лучше.А пробовали, как выше предлагает @fk0, объявить ссылку на функцию? Как-то так:
По моим грубым прикидкам для этого нужно положить на депозит примерно 1,5 млрд рублей. Не каждая компания может похвастаться подобным дневным оборотом.
А что не так с редмайном? Я помню его как довольно приятный багтрекер. Судя по официальному сайту, проект до сих пор живой (в декабре был последний стабильный релиз). Чем он не современный-то?
Потому что студенты должны знать общепринятые терминологию, обозначения и имена, это часть профессиональной квалификации.
И ещё потому, что развёрнутый вопрос содержит в себе половину ответа. Если студент забыл, какой из признаков сходимости второй, пусть напишет все, какие знает.
Какой-то супернеудачный перевод. Ну не придумывайте вы своих терминов: во всём гугле нет ни одного результата по запросу "стратегия наименее использованного результата" (в кавычках).
Я не опытный мастер из "Яндекса", но, кажется, догадываюсь, в чём дело. Человек не "не может" прочитать код, он не хочет его читать, потому что он выглядит как нагромождение строк и не воспринимается взглядом, его нужно декодировать. Этого достаточно для отказа.
Предположу, что собеседующий хотел увидеть декомпозированное на несколько функций решение, как-то так:
Или использовать операцию умножения, которая здесь очень подходит по смыслу. Например, если понимать обозначение «кг» как синоним величины «1 кг», а «м³» — как синоним «1 м³» (то есть «1 м ⋅ 1 м ⋅ 1 м»), то можно весьма вольно обращаться с числами и единицами измерения:
20*(kg/m3) == (20*kg)/m3 == (20*kg/m)/m2Так, кстати, сделано в Boost.Units.
Удивительное сочетание алгоритмов! Если у вас уже есть криптостойкая контрольная сумма, зачем добавлять к ней CRC-32? Кстати, а почему SHA-3?
Чтобы это работало, в реализациии
OrderByдолжна использоваться устойчивая сортировка. В то же время, SQL-операторORDER BYне гарантирует устойчивость. Поэтому я бы не поручился за то, что все провайдеры LINQ-to-SQL правильно обработают это ваше.OrderBy().OrderBy().Неужели вообще кто-то так делает? Откуда возникла идея написать статью на тему «сравним в подробностях два способа сделать сортировку: очевидно правильный, быстрый и предсказуемый и очевидно неправильный, медленный и с граблями»?
Например, для того, чтобы заранее определиться с именами классов и файлов и поменьше переименовывать потом в процессе. Переименовывать файлы при рефакторинге неудобно, потому что затрагивает систему контроля версий. Ещё имена имеют тенденцию цепляться друг за друга, поэтому может получиться, что из-за одного непродуманного названия нужно будет переименовать дюжину файлов и кучу переменных внутри них.
Потому что агрится на псевдокод и отвлекает внимание инспекциями и подчёркиваниями. Если же лень покидать IDE, я частенько открываю многострочный комментарий прямо по месту и в нём уже прикидываю алгоритм, а потом переношу в код.
Имхо, как раз на этапе проектирования черновик полезнее всего. Допустим, хотите вы добавить какую-то новую функциональность: открываете чистую вкладку в блокноте, пишете пример-другой кода так, как если бы то, что вы хотите спроектировать уже было готово, рядом прикидываете, какие классы нужны, в какие неймспейсы их поместить, что должно быть внутри этих классов, долго выбираете всему этому как можно более логичные и последовательные имена, перераспределяете области ответственности, смотрите, что можно декомпозировать и переиспользовать.
Для всего этого IDE не нужна и будет только мешаться.
А я вот пишу, на бумаге и в Notepad++, псевдокодом, с сокращениями. Так ведь удобнее думать, нет? Понять, что от чего должно зависеть, прикинуть, какие у класса должны быть методы и как вообще лучше разбить задачу на классы.
Сколько лет вижу в статьях этот аргумент, столько лет понять не могу: люди, как вы вообще можете думать в IDE, без псевдокода, схем и рисунков?