Зависит от имплементации, конечно, эффекты могут быть разными. 1) Может получиться так что архитектор будет союзником продактов и их проводником в мир "как у нас всё устроено", - тогда кажется это может быть эффективным. Но это я бы назвал техлидом, нежели архитектором в классическом понимании. Такой позиции я и старался придерживаться в свое время в Почте@mail.ru 2) Товарищ, который сочиняет как что должно выглядеть. Придумывает сервисы, и интеграции, которые потом имплементят другие. Это тупиковый путь, на мой взгляд. Потому что со временем этот "архитектор" отрывается от реальности, сочиняет всякое, придумывает сервисы и называет их именами, которые "во внешнем мире" заняты каким-то другим концептом. В итоге, с годами, товарищ становится просто фантазером, а не носителем современных практик. Дальше, чтобы удерживать свою надобность - воркфлоу переходит в стадию (3). 3) Архитектор-аппрувер. Такими эффектами иногда грешат оч крупные развесистые компании (можете предположить какие). Товарищи давно ничего не понимают в том как что строить, а просто в лучшем случае разрешают или не разрешают ту или иную активность. В худшем случае - занимаются "пропихиванием"(при помощи админ ресурса) того, что сами сочли нужным и удачным решением. 4) Наиболее удачный вариант на мой взгляд. Кворум техлидов. Это позволяет ребятам вместе принимать решения и учиться. Учиться проектировать, договариваться, осознавать ошибки на практике. Я считаю так наиболее правильно. Не один человек пусть учится проектировать, а все. Но в этом случае - выделенного архитектора нет ведь. Это просто дополнительная роль техлидов. Как peer-ревьюят код - они взаиморевьюят архитектурные решения.
P.S. Когда я был сеньором/техлидом - я хотел чтобы появилась выделенная роль архитектора (и чего греха таить, сам метил в неё). Теперь когда я отвечаю за техничку и процессы в ней - мне видится что запускать что либо, кроме (4) - преступление против здравого смысла.
Архитекторство как явление - большой простор для фантазий и умозрительных вымыслов. Многие разработчики хотят и становятся архитекторами, чтобы творить и концентрироваться на фантазёрстве. В этом бич всей этой области знаний. Сам занимал похожую должность, и хоть и старался на эти грабли наступать - сделать это бывает не так-то просто.
Итого, я пришел к выводу, что выделенный архитектор в команде - скорее явление вредное, чем полезное. Он концентрируется на своём "творчестве", не оставляя остальным ребятам места для принятия решений, замедляя развитие команды и создавая больше бюрократических процедур.
Интересно было бы в какой разряд можно отнести LCSC? Они не официальный дистрибьютор?
Вообще, если например хочу закупиться оригиналами всяких Ti, IR итд (для особо-ответственных задач) — это только в раздел «Глобальные дистрибьюторы», больше никуда?
Про хайп не знаю, я не спец в этом. Вряд ли хайп помог бы автору починить проблему на проде.
Про баги — там могло не быть детских багов по двум причинам: а) автор знает Go намного лучше чем Rust (это плюс в сторону выбора Go) и б) Go не допускает глупых ошибок (это плюс в сторону выбора Go).
Про ущерб сообществу это просто смешно. Оно слабое, в том числе по этой причине выбор был сделан правильно. Поясню:
В изначальной статье 3им пунктом было «Большое сообщество, позволяющее быстро найти ответы на вопросы». Т.е. сильное сообщество нужно, чтобы делать задачи без лишних головняков, а также сильное ревью и так далее. Так вот, это сообщество нашло эту кажется простую ошибку спустя только 2 года. Выходит, проблема была и до статьи, что только добавляет очков к Go.
Код кажется не оптимальным. Много syscall-ов (отдельный вызов на каждый токен). Это может привести к большому количеству context switch и как следствие заметное замедление сервиса.
Я не знаю C#, возможно ReadUntil* внутри содержит буффер, где копит данные «на следующие чтения» — тогда сисколов много не будет, но тогда будет плохо предсказуемое потребление памяти. Ну, еще я бы это не назвал конечным автоматом.
Вариант с автоматом не так зависит от количества хедеров и имеет более «ровное» потребление памяти одновременно.
Статья никак не научная, однако с основными утверждениями согласен, для этого есть куча доказательств, которые и в 10 статей не влезут. Большинство софта из ряда вон кака, как и железо. Мне лично непонятно и удивительно как это все работает, хотя занимаюсь этим всем уже лет 15.
Нет, раз уж опять про коллизии, давайте окончательно разделим 2 кейса:
1. Случайное совпадение — об этом см пост выше. Гораздо вероятнее, что вы допустите ошибку и все разломается до того, как возникнет шанс на такой случай.
2. Саботаж (направленная атака). Статистика тут действительно не работает, однако: 1)хеш соленый 2) хеш наружу не отдается никогда 3)атакуемый хеш не известен 4) сложно подобрать подходящий атакуемому хешу файл 5) еще сложнее — если он соленый 6) еще сложнее — если он неизвестно как соленый 7) подобрав саботажную коллизию (в чем я категорически сомневаюсь с учетом вышесказанного) остается вопрос — в файле будут данные или мусор? 8) Если мусор то такой «саботаж» отклоняется за 5минут отправкой ссылки в любое другое хранилище документа, либо его изменением.
Обобщая все вопросы в комментариях про коллизии я для себя выводы сделал. Все слышали про теоретическую возможность; никто не делал ни единого верного шага на предмет как это сделать(и я тоже). Так что простите великодушно, я уже все что мог на эту тему написал.
К сожалению, железо несовершенно и разработчики тоже. Как ни крути — будут баги программные, хардварные и разные ситуации. Наивно надеятся, что багов не будет, как бы вы не были аккуратны. При большой нагрузке ошибки будут, причем самые неожиданные. В этом ключе существует только 2 варианта: counter умеет ошибаться с бОльшую сторону, либо в меньшую. Конечно, лучше первое=) Процент неудаляемых файлов реально очень мал (<0.001%).
Небольшой перечень ситуаций, ведущих к ошибкам в counter:
— Ребут сервера
— Отказ диска
— Сетевая проблема (запрос на уменьшение дошел, а ответ на этот запрос — нет)
— Перегруз сервера filedb (запрос будет исполнен, но уже после таймаута)
— Баги (вклюючая segfault в любой части этой системы)
— Затуп в диск при логировании в async приложении приведет к таймаутам
— Наверняка еще 100500 кейсов, которые я сейчас не вижу
А как можно «защитить» sha1 от коллизий? Есть проверка, что это именно тот sha1, который был в письме (путем подсчета еще одной контрольной суммы). А защититься в полном смысле я думаю нельзя. Так что да, файл в новом письме не сохранится, в этом случае мы будем первыми в мире, кто найдет такой коллизию=) Пока на 12млрд хешей такого не произошло, по подсчетам z3apa3a этого не произойдет, пока хранилище не увеличится еще в 1e20 раз. Так что реально нет причин полагать, что такая проблема есть фактически.
P.S. Интересно вот что: ваши вопросы натолкнули меня на мысль) Почему так много вопросов про коллизии и так мало про счетчик? А ведь вероятность ошибиться в счетчике в результате бага и железной проблемы в миллиарды раз выше, чем вероятность коллизии. Перефразирую: есть сотни реальных(вероятность >1e1000) кейсов, когда счетчик разойдется и ни одного прецедента с коллизией.
Ну если самих хешей 12млрд, а у каждого счетчик >=1, то сколько же таких записей будет?
Это затратно по ресурсам. Плюс еще есть такой фактор как консистентность: сейчас авторитетным источником для любого рода информации являются индексы писем. Если начать хранить обратные ссылки то рано или поздно возникнет ситуация, что информация не сходится, что тогда делать?
Их добавляет сам таранул для того чтобы уметь разобрать тапл на поля. По крайне мере в 1.5 так. Тут хотелось бы напомнить, что сам тарантул тоже должен уметь разбирать на поля т.к. работает с многими полями записей filedb на уровне луашек. Можно было бы это обойти, но тогда возникли бы вопросы по атомарности изменений в этих полях, так что я бы не стал=)
Если кратко то пока никак не корректируется. Ставится флаг, что удалять нельзя.
В принципе, в планах есть приблизительно такой вариант: запомнить какой был counter&magic у таких хешей и начать обход по индексам. В результате обхода получаем какой должен быть counter&magic и обновляем их в filedb а-ля «compare and swap». Пока(тфутфу) таких «бессмертных файлов» особо и нет(по факту есть в тестовых ящиках) — задача не горит. Мы больше концентрируемся на том, чтобы они в этот разряд не попадали, т.к. любая подобная сверка — масштабная нежелательная операция. Так что на мой взгляд тут задача №1 — не давать попадать файлам в этот разряд и задача №2 — не сломать возможность сверки, если вдруг Вселенная восстанет против нас.=)
Описанные в статье (в разделе про валькирию) 2 вида карантина, плюс отложенное удаление на одной из пар. В случае чего — можно легко найти потерянный файл и закинуть обратно в облако с пометкой «не удалять», а потом устроить масштабные разборы полетов=) К счастью, пока не доводилось)
В вашем примере чтобы такое произошло, нужно чтобы при заданном magic2 значения magic1 и magic3 были вполне конкретные (возможны варианты, но их множество очень ограничено). Выходит, что вероятность этого события сопоставима с 1/ (2^32 * 2^32)
Там пройди тренинг на интервьюера и походи-пособеседуй, много нового узнаешь...
Зависит от имплементации, конечно, эффекты могут быть разными.
1) Может получиться так что архитектор будет союзником продактов и их проводником в мир "как у нас всё устроено", - тогда кажется это может быть эффективным. Но это я бы назвал техлидом, нежели архитектором в классическом понимании. Такой позиции я и старался придерживаться в свое время в Почте@mail.ru
2) Товарищ, который сочиняет как что должно выглядеть. Придумывает сервисы, и интеграции, которые потом имплементят другие. Это тупиковый путь, на мой взгляд. Потому что со временем этот "архитектор" отрывается от реальности, сочиняет всякое, придумывает сервисы и называет их именами, которые "во внешнем мире" заняты каким-то другим концептом. В итоге, с годами, товарищ становится просто фантазером, а не носителем современных практик. Дальше, чтобы удерживать свою надобность - воркфлоу переходит в стадию (3).
3) Архитектор-аппрувер. Такими эффектами иногда грешат оч крупные развесистые компании (можете предположить какие). Товарищи давно ничего не понимают в том как что строить, а просто в лучшем случае разрешают или не разрешают ту или иную активность. В худшем случае - занимаются "пропихиванием"(при помощи админ ресурса) того, что сами сочли нужным и удачным решением.
4) Наиболее удачный вариант на мой взгляд. Кворум техлидов. Это позволяет ребятам вместе принимать решения и учиться. Учиться проектировать, договариваться, осознавать ошибки на практике. Я считаю так наиболее правильно. Не один человек пусть учится проектировать, а все. Но в этом случае - выделенного архитектора нет ведь. Это просто дополнительная роль техлидов. Как peer-ревьюят код - они взаиморевьюят архитектурные решения.
P.S. Когда я был сеньором/техлидом - я хотел чтобы появилась выделенная роль архитектора (и чего греха таить, сам метил в неё). Теперь когда я отвечаю за техничку и процессы в ней - мне видится что запускать что либо, кроме (4) - преступление против здравого смысла.
Архитекторство как явление - большой простор для фантазий и умозрительных вымыслов. Многие разработчики хотят и становятся архитекторами, чтобы творить и концентрироваться на фантазёрстве. В этом бич всей этой области знаний. Сам занимал похожую должность, и хоть и старался на эти грабли наступать - сделать это бывает не так-то просто.
Итого, я пришел к выводу, что выделенный архитектор в команде - скорее явление вредное, чем полезное. Он концентрируется на своём "творчестве", не оставляя остальным ребятам места для принятия решений, замедляя развитие команды и создавая больше бюрократических процедур.
Вообще, если например хочу закупиться оригиналами всяких Ti, IR итд (для особо-ответственных задач) — это только в раздел «Глобальные дистрибьюторы», больше никуда?
Про баги — там могло не быть детских багов по двум причинам: а) автор знает Go намного лучше чем Rust (это плюс в сторону выбора Go) и б) Go не допускает глупых ошибок (это плюс в сторону выбора Go).
В изначальной статье 3им пунктом было «Большое сообщество, позволяющее быстро найти ответы на вопросы». Т.е. сильное сообщество нужно, чтобы делать задачи без лишних головняков, а также сильное ревью и так далее. Так вот, это сообщество нашло эту кажется простую ошибку спустя только 2 года. Выходит, проблема была и до статьи, что только добавляет очков к Go.
Я не знаю C#, возможно ReadUntil* внутри содержит буффер, где копит данные «на следующие чтения» — тогда сисколов много не будет, но тогда будет плохо предсказуемое потребление памяти. Ну, еще я бы это не назвал конечным автоматом.
Вариант с автоматом не так зависит от количества хедеров и имеет более «ровное» потребление памяти одновременно.
1. Случайное совпадение — об этом см пост выше. Гораздо вероятнее, что вы допустите ошибку и все разломается до того, как возникнет шанс на такой случай.
2. Саботаж (направленная атака). Статистика тут действительно не работает, однако: 1)хеш соленый 2) хеш наружу не отдается никогда 3)атакуемый хеш не известен 4) сложно подобрать подходящий атакуемому хешу файл 5) еще сложнее — если он соленый 6) еще сложнее — если он неизвестно как соленый 7) подобрав саботажную коллизию (в чем я категорически сомневаюсь с учетом вышесказанного) остается вопрос — в файле будут данные или мусор? 8) Если мусор то такой «саботаж» отклоняется за 5минут отправкой ссылки в любое другое хранилище документа, либо его изменением.
Обобщая все вопросы в комментариях про коллизии я для себя выводы сделал. Все слышали про теоретическую возможность; никто не делал ни единого верного шага на предмет как это сделать(и я тоже). Так что простите великодушно, я уже все что мог на эту тему написал.
Небольшой перечень ситуаций, ведущих к ошибкам в counter:
— Ребут сервера
— Отказ диска
— Сетевая проблема (запрос на уменьшение дошел, а ответ на этот запрос — нет)
— Перегруз сервера filedb (запрос будет исполнен, но уже после таймаута)
— Баги (вклюючая segfault в любой части этой системы)
— Затуп в диск при логировании в async приложении приведет к таймаутам
— Наверняка еще 100500 кейсов, которые я сейчас не вижу
А как можно «защитить» sha1 от коллизий? Есть проверка, что это именно тот sha1, который был в письме (путем подсчета еще одной контрольной суммы). А защититься в полном смысле я думаю нельзя. Так что да, файл в новом письме не сохранится, в этом случае мы будем первыми в мире, кто найдет такой коллизию=) Пока на 12млрд хешей такого не произошло, по подсчетам z3apa3a этого не произойдет, пока хранилище не увеличится еще в 1e20 раз. Так что реально нет причин полагать, что такая проблема есть фактически.
P.S. Интересно вот что: ваши вопросы натолкнули меня на мысль) Почему так много вопросов про коллизии и так мало про счетчик? А ведь вероятность ошибиться в счетчике в результате бага и железной проблемы в миллиарды раз выше, чем вероятность коллизии. Перефразирую: есть сотни реальных(вероятность >1e1000) кейсов, когда счетчик разойдется и ни одного прецедента с коллизией.
Это затратно по ресурсам. Плюс еще есть такой фактор как консистентность: сейчас авторитетным источником для любого рода информации являются индексы писем. Если начать хранить обратные ссылки то рано или поздно возникнет ситуация, что информация не сходится, что тогда делать?
В принципе, в планах есть приблизительно такой вариант: запомнить какой был counter&magic у таких хешей и начать обход по индексам. В результате обхода получаем какой должен быть counter&magic и обновляем их в filedb а-ля «compare and swap». Пока(тфутфу) таких «бессмертных файлов» особо и нет(по факту есть в тестовых ящиках) — задача не горит. Мы больше концентрируемся на том, чтобы они в этот разряд не попадали, т.к. любая подобная сверка — масштабная нежелательная операция. Так что на мой взгляд тут задача №1 — не давать попадать файлам в этот разряд и задача №2 — не сломать возможность сверки, если вдруг Вселенная восстанет против нас.=)