Человек выполняет техническую часть исследования, рождающиеся в процессе этого данные прямиком уходят к ИИ этого человека минуя.
Нет. ИИ хорошо ищет по образцу, а этих образцов ему скормили много. Он не устаёт и не отвлекается на личность пациента и на прочие ненужные штуки.
Поэтому то, что можно определить по ассоциации, он определит и сделает это очень хорошо. Например, заметит на рентгене характерные для какого-то заболевания затемнения.
Кроме того, у него в голове куча сведений, и он ищет по ним, как очень продвинутый поисковик.
Если кроме перечисленного вы сами ничего не умеете, у меня для вас плохие новости.
Но человек, в отличии от ИИ, умеет не только выявлять ассоциации и искать по массиву данных, но еще и думать. Есть сильные сомнения, что на этом поприще ИИ когда-либо догонит живого человека.
Вы "подписали" функци на событие. Произошло событие. Её позвали. Она сама сгенерировала еще одно событие. Её опять позвали. И так по кругу, пока стек не кончится.
может быть несколько одинаковых функций для одного события;
Вот кому может понадобиться дважды подписать одну функцию? Если кто-то так сделает, это ж явная ошибка. Не лучше ли это контролировать, бросаться там исключениями, если такое произойдет, чем городить огород, пытаясь это поддержать.
И второй вопрос, что будет, если обработчик событий сам позовёт emit?
Надо не забывать еще, что в реальной жизни кроме асимптотического приближения есть еще и коэффициент. И алгоритмы с хорошей асимптотой имеют тенденцию обладать большим коэффициентом. И поэтому могут проигрывать простым алгоритмам, когда данных мало.
Посыл с моей стороны в том, что если вы, дорогие товарищи, считаете себя специалистами по ИБ - то ваша задача, это разработать и внедрить такие процедуры, которые будут обеспечивать эту самую ИБ. не заставляя пользователей выбирать между невозможным существованием и тихим саботажем ваших усилий.
Пока же я вижу в основном, что вы что-то там себе понапридумывали, и пытаетесь заставить пользователей жить по вашим правилам.
Есть разница между информацией и случайным набором букв.
Информация имеет смысл и вписана в общую информационную картину человека. Случайный набор букв смысла не имеет.
Существует полно людей, у которых всё хорошо с умением хранить, оперировать, анализировать осмысленные знания, но вот номера телефонов, кредитных карт и пароли они запоминают с трудом.
Причём можно бы еще разок поднапрячься и запомнить. Но ваши же коллеги требуют пароль раз в три месяца менять. И их человеку надо много иметь. Один для офиса, другой для банка, третий для хабра...
В итоге, менеджмент паролей становится непреодолимой задачей. И приходится решать её всякими костылями: хранить пароли в менеджере паролей с риском, что они оттуда утекут, записывать на бумажке, использовать пароли типа !B(B#-2, B($B#-3 и т.п.
Всё это ослабляет а не усиливает реальную безопасность.
Ещё полгода назад были слышны жаркие дискуссии о том, сможет ли ИИ заменить разработчиков или нет. Незаметно, эта дискуссия сместилась в сторону того, какая именно роль отводится разработчикам в будущем.
А не получается ли так, что сильные пароли, да еще и с обязательной регулярной заменой и с проверкой, что пользователь не пытается повторить старый пароль, кончают свою жизнь в виде жёлтой бумажки, приклеенной к монитору, потому, что их невозможно запомнить?
testing/synctest — наконец нормальное тестирование конкурентного кода
Не конкурентного кода, а кода, который реализует алгоритмы, работающие с реальным временем. Например, сетевой протокол, который может делать перепосылку, если данные не дошли в ожидаемое время.
Если кратко, стоит посмотреть на такие краевые случаи:
Пустой массив или строка
Массив с одним элементом
Отрицательные элементы в массиве
Итерации в начале и в конце массива (моё любимое, не забудьте проверить, где находится указатель в конце цикла, возможно, придётся сделать ещё одну итерацию)
А в боевом коде, не на собесе, вы не смотрите на такие краевые случаи?
Но это, очевидно, костыль, хоть и весьма надёжно работающий. По-хорошему, стоило бы довести это дело до ума (т.е., или понять, что это ошибка ядра и добиться включения в ядро исправлений, или понять, что это какая-то ошибка в машинке и починить её).
Смущает то, что всё задействованное железо очень стандартное (и находится внутри интеловского чипсета), но при этом сама по себе проблема специфична для конкретного изделия (и нескольких похожих, там есть ссылки на упоминания других моделей).
В общем, если не сложно, обратите, пожалуйста, внимание ребят, которые этим занимаются в вашей компании, на существование проблемы и наличие костыльного решения для нее.
Отдельно хочу обратить внимание на последний параграф.
Возврат errno по значению вносит сумятицу, когда невозможно выделить какое-то специальное невалидное значение
Особенно обидно, когда для всех функций API он подходит, а для парочки каких-то надо изобретать отдельный механизм
Ну и конечно, то, что в UNIX все функции при ошибке возвращают -1, а pthread_XXX - 0, не добавляет удобства.
В этом плане, конечно, Go-ный подход, возвращающий ошибку отдельным значением (или подход языков с алгебраическими типами, возвращающими результат или ошибку через maybe-тип) выглядит более удачным. Но если API на Си, тут, наверное, совсем уж хорошо не сделаешь...
Нет. ИИ хорошо ищет по образцу, а этих образцов ему скормили много. Он не устаёт и не отвлекается на личность пациента и на прочие ненужные штуки.
Поэтому то, что можно определить по ассоциации, он определит и сделает это очень хорошо. Например, заметит на рентгене характерные для какого-то заболевания затемнения.
Кроме того, у него в голове куча сведений, и он ищет по ним, как очень продвинутый поисковик.
Если кроме перечисленного вы сами ничего не умеете, у меня для вас плохие новости.
Но человек, в отличии от ИИ, умеет не только выявлять ассоциации и искать по массиву данных, но еще и думать. Есть сильные сомнения, что на этом поприще ИИ когда-либо догонит живого человека.
Вы "подписали" функци на событие. Произошло событие. Её позвали. Она сама сгенерировала еще одно событие. Её опять позвали. И так по кругу, пока стек не кончится.
Вот кому может понадобиться дважды подписать одну функцию? Если кто-то так сделает, это ж явная ошибка. Не лучше ли это контролировать, бросаться там исключениями, если такое произойдет, чем городить огород, пытаясь это поддержать.
И второй вопрос, что будет, если обработчик событий сам позовёт emit?
Надо не забывать еще, что в реальной жизни кроме асимптотического приближения есть еще и коэффициент. И алгоритмы с хорошей асимптотой имеют тенденцию обладать большим коэффициентом. И поэтому могут проигрывать простым алгоритмам, когда данных мало.
Небось, если бы мы оказались с вами в одной организации и мой начальник был бы дурак, вы бы добились моего увольнения :)
Тут и обвинения в некомпетенции, и саботаж...
Скоры вы на обвинения, однако.
Я, всё же, пытаюсь разговаривать с вами, как инженер с инженером. Пытаюсь показать вам, что инженеру тут есть к чему приложить умственные усилия.
Если же вы видите себя в этой конструкции в позиции вахтёра, задача которого - добиться исполнения установленных кем-то правил, ну ОК, воля ваша.
Нет, батенька.
Посыл с моей стороны в том, что если вы, дорогие товарищи, считаете себя специалистами по ИБ - то ваша задача, это разработать и внедрить такие процедуры, которые будут обеспечивать эту самую ИБ. не заставляя пользователей выбирать между невозможным существованием и тихим саботажем ваших усилий.
Пока же я вижу в основном, что вы что-то там себе понапридумывали, и пытаетесь заставить пользователей жить по вашим правилам.
Есть разница между информацией и случайным набором букв.
Информация имеет смысл и вписана в общую информационную картину человека. Случайный набор букв смысла не имеет.
Существует полно людей, у которых всё хорошо с умением хранить, оперировать, анализировать осмысленные знания, но вот номера телефонов, кредитных карт и пароли они запоминают с трудом.
Причём можно бы еще разок поднапрячься и запомнить. Но ваши же коллеги требуют пароль раз в три месяца менять. И их человеку надо много иметь. Один для офиса, другой для банка, третий для хабра...
В итоге, менеджмент паролей становится непреодолимой задачей. И приходится решать её всякими костылями: хранить пароли в менеджере паролей с риском, что они оттуда утекут, записывать на бумажке, использовать пароли типа !B(
B#-2, B($B#-3 и т.п.
Всё это ослабляет а не усиливает реальную безопасность.
Токены, кстати, неплохой вариант.
Пользователь может обладать 100500 полезных компетенций, но не обладать при этом компетенцией запоминать всякую бессодержательную чушь.
Интересно, если вы заболеете, вы выберете хирурга с золотыми руками или хирурга, который хорошо пароли запоминает?
Если правила не работают, надо правила чинить, а не людей кошмарить
Ну да, я понимаю. И без того работа тяжелая, а тут еще и люди мешают...
"Security community now worries about security, not users.
User interface makes security unworkable"
"Weak security that’s easy to use will help more people than strong
security that’s hard to use. E.g.: door locks"
"Bad user interfaces drive people away from security.
Weak security is much better than none at all"
--
Rob Pike. The Good, the Bad, and the Ugly: The Unix Legacy
http://herpolhode.com/rob/ugly.pdf
Очень смелое утверждение
А не получается ли так, что сильные пароли, да еще и с обязательной регулярной заменой и с проверкой, что пользователь не пытается повторить старый пароль, кончают свою жизнь в виде жёлтой бумажки, приклеенной к монитору, потому, что их невозможно запомнить?
А ему точно можно доверять?
Не конкурентного кода, а кода, который реализует алгоритмы, работающие с реальным временем. Например, сетевой протокол, который может делать перепосылку, если данные не дошли в ожидаемое время.
А в боевом коде, не на собесе, вы не смотрите на такие краевые случаи?
О, замечательно.
Тут с квадрой вышла вот такая штука, может вам будет интересно:
https://github.com/alexpevzner/hotfix-kvadra-touchpad
https://lkml.iu.edu/2502.0/01814.html
Но это, очевидно, костыль, хоть и весьма надёжно работающий. По-хорошему, стоило бы довести это дело до ума (т.е., или понять, что это ошибка ядра и добиться включения в ядро исправлений, или понять, что это какая-то ошибка в машинке и починить её).
Смущает то, что всё задействованное железо очень стандартное (и находится внутри интеловского чипсета), но при этом сама по себе проблема специфична для конкретного изделия (и нескольких похожих, там есть ссылки на упоминания других моделей).
В общем, если не сложно, обратите, пожалуйста, внимание ребят, которые этим занимаются в вашей компании, на существование проблемы и наличие костыльного решения для нее.
Хм. Можно было бы сэкономить один байт, сказав
mov ax, .... А можно было бы иint 20hсказать, без mov-ов...Обычные люди рано или поздно это узнают. Вот например, сегодня Вы узнали...
Возврат
errnoпо значению вносит сумятицу, когда невозможно выделить какое-то специальное невалидное значениеОсобенно обидно, когда для всех функций API он подходит, а для парочки каких-то надо изобретать отдельный механизм
Ну и конечно, то, что в UNIX все функции при ошибке возвращают -1, а pthread_XXX - 0, не добавляет удобства.
В этом плане, конечно, Go-ный подход, возвращающий ошибку отдельным значением (или подход языков с алгебраическими типами, возвращающими результат или ошибку через maybe-тип) выглядит более удачным. Но если API на Си, тут, наверное, совсем уж хорошо не сделаешь...