конечно, правда не на плоскости, а нужно повернуть крышку перпендикулярно люку, и разместить по диагонали, что случайно маловероятно. А так не будут проваливаться любые фигуры, у которых разница между минимальным и максимальным радиусом (от геометрического центра) не больше ширины паза. при ширине паза == 0 — это только круг.
Я могу тут начать дискуссию, правда она не очень связана из изначальной темой обсуждения.
Фрилансеры правда, увы, сразу «выпадают». Почему люди идут в фриланс (достаточно одного из четырех пунктов):
1. желание получать больше денег за ту же работу,
2. возможность иметь столько работы, на сколько хватает времени,
3. неумение или отсутствие желания общаться с коллективом, подстраиваться под начальство,
4. отказ от выполнения «неинтересных» задач, попытка выбрать то, что тебе «по душе».
А теперь попробуем построить worst-case (это важно! ибо это не обязательно вытекает из вышеописанного) аналогию тех же тезисов в плане «отношений»:
1. некоторая жадность,
2. трудоголизм, нежелание (или неумение) балансировать время,
3. эгоцентризм,
4. уход «от реальности».
Разумеется, при наличии хотя бы одного из этих пунктов с «отношениями» будут сложности. Более одного — ничего не получится.
Я же подразумевал типичного «офисного» программиста, проводящего на работе не более 8 часов, как это и положено, по ТК.
И теперь, подхожу к мысли, которая, возможно не многим будет по душе, но… железки хороши на работе, за деньги компании, в их офисах. Обучение новым технологиям, не связанным непосредственно с рабочим проектом — тоже в офисе.
Если же у вас (собирательный образ) дедлайны, оверворк, отказы на оборудование для экспериментов, нет возможности иметь карьерное развитие, то, вероятно:
1. вы достигли своего уровня некомпетентности (то бишь выбрали лучшее по деньгам или другим факторам рабочее место, куда вас смогли пригласить),
2. у вас просто плохая работа.
То есть заняться этим вопросом лучше в первую очередь, а потом уже переходить на вопрос «отношений».
А на мой взгляд, прекрасно читается. По факту, конечно, текст состоит из нескольких самоочевидных фактов, но авторский стиль помогает от набора тезисов перейти к связному изложению.
во-первых «завести» несколько некорректный тезис, заводят всякие другие вещи, и обычно нежелательные :)
а во-вторых, за «нас» наверное не стоит говорить, ибо в целом программисту справиться с этой задачей значительно проще, чем большинству людей, не работающих в IT, потому как:
* много свободного времени;
* материальная обеспеченность, стабильность;
* низкий стресс-фактор от работы, и как следствие большое количество жизненных сил, остающихся на послерабочее время.
Дело в том, что в парадигму ООП разделение интерфейсов и абстрактных классов попросту не входит. Таким образом — этот вопрос, просто привязка к конкретным языкам, где нет честного множественного наследования. Если человек устраивается как специалист узкого профиля — ему это знать не нужно, не обязательно игнорировать специально, но есть существенная вероятность, что пока он с этими вопросами и не сталкивался.
именно так и отвечал, а товарищи из HR настаивали, что это неверный ответ.
То есть круглый люк не может провалиться внутрь, но не проваливается сам и под нагрузкой он благодаря тому что есть специальный паз, диаметр люка больше, чем диаметр отверстия. Квадратный с таким же пазом, не провалится.
Антивандальные соображения? Ну да, это «for fun» поднимать тяжеленные квадратные люки, ставить по диагонали, чтобы уронить внутрь. А вот круглый можно поднять и укатить на ближайший прием металлолома.
> Также слабым местом хэш-скана является скорость проверки.
В каком же простите месте? Самым слабым местом всегда является скорость считывания с диска, а посчитать мд5 хеш (хотя что-то слабо верится что именно по хешу сравнение, а не по шаблонам) и найти в списке сигнатур (пусть даже среди нескольких миллионов) хеш-поиском (да хоть бинарным) — вопрос нескольких долей миллисекунды.
Читать конечно никто не заставляет, но вы ошибаетесь. Не в существовании быстрых хранилищ, а в том насколько они быстрые должны быть — десятки миллисекунд (точнее «десяток») * 5000 запросов (на один хеш) как раз и дают минуту.
1. Если таблицы отсортированы и у них есть индекс, то найти одно значение можно за десятки миллисекунд (предполагаем, что индекс уже в памяти, а вот к конкретному месту в файле уже придется обращаться), всего таких операций на одно значение нужно 5000 (в моем случае) — дает минуту (приблизительно, т.к. сильно зависит от параметров железа, вдруг все таблицы в память влезают?).
2. потому что хеш таблица хорошо работает, только если она слабо заполнена (<30%), что в случае 5.7 миллионов элементов (*8 байт) требует больше памяти, чем есть на моей видяхе. А по первым результатам хеш-поиск на основном ядре при оптимальных параметрах сливает бинарному на видеокарте.
3. ну это и не «мой метод», просто разновидность частотного анализа, немного упрощенная для эффективной реализации.
за опровержение эту статью считать нельзя: теоретическая выкладка завязана на сюръективность хеш-функций, а это свойство не доказано.
А для усеченного md5 хеша могут действовать другие правила, нежели для полного, опять же, доказательство идентичности свойств отсутствует.
Так что не уверен, когда я генерил таблицы для MD5 с фиксированной функцией редукции и цепочкой длины 10000 — было жуткое количество коллизий при наборе символов сравнимом по мощности с разрядностью хеш-значения.
Не стоит на это закладываться. Но да, массовый перебор будет соответственно в миллион раз медленнее — и на ближайшие пару лет взломщиков это остановит.
Но да, нагрузка на сервер при этом возрастает ужасно, и для высоконагруженного решения — идея не приемлема.
Пароль + соль, а лучше сразу bcrypt — значительно надежнее/удобнее.
да, как раз дело в том, что частотный словарь, он небольшой совсем, те 2.5 миллиона получились благодаря словарю всего на 40кб, полученному после первых двух шагов.
Фрилансеры правда, увы, сразу «выпадают». Почему люди идут в фриланс (достаточно одного из четырех пунктов):
1. желание получать больше денег за ту же работу,
2. возможность иметь столько работы, на сколько хватает времени,
3. неумение или отсутствие желания общаться с коллективом, подстраиваться под начальство,
4. отказ от выполнения «неинтересных» задач, попытка выбрать то, что тебе «по душе».
А теперь попробуем построить worst-case (это важно! ибо это не обязательно вытекает из вышеописанного) аналогию тех же тезисов в плане «отношений»:
1. некоторая жадность,
2. трудоголизм, нежелание (или неумение) балансировать время,
3. эгоцентризм,
4. уход «от реальности».
Разумеется, при наличии хотя бы одного из этих пунктов с «отношениями» будут сложности. Более одного — ничего не получится.
Я же подразумевал типичного «офисного» программиста, проводящего на работе не более 8 часов, как это и положено, по ТК.
И теперь, подхожу к мысли, которая, возможно не многим будет по душе, но… железки хороши на работе, за деньги компании, в их офисах. Обучение новым технологиям, не связанным непосредственно с рабочим проектом — тоже в офисе.
Если же у вас (собирательный образ) дедлайны, оверворк, отказы на оборудование для экспериментов, нет возможности иметь карьерное развитие, то, вероятно:
1. вы достигли своего уровня некомпетентности (то бишь выбрали лучшее по деньгам или другим факторам рабочее место, куда вас смогли пригласить),
2. у вас просто плохая работа.
То есть заняться этим вопросом лучше в первую очередь, а потом уже переходить на вопрос «отношений».
Это же не «how to» какое-нибудь :)
а во-вторых, за «нас» наверное не стоит говорить, ибо в целом программисту справиться с этой задачей значительно проще, чем большинству людей, не работающих в IT, потому как:
* много свободного времени;
* материальная обеспеченность, стабильность;
* низкий стресс-фактор от работы, и как следствие большое количество жизненных сил, остающихся на послерабочее время.
То есть круглый люк не может провалиться внутрь, но не проваливается сам и под нагрузкой он благодаря тому что есть специальный паз, диаметр люка больше, чем диаметр отверстия. Квадратный с таким же пазом, не провалится.
Антивандальные соображения? Ну да, это «for fun» поднимать тяжеленные квадратные люки, ставить по диагонали, чтобы уронить внутрь. А вот круглый можно поднять и укатить на ближайший прием металлолома.
«Ибо ничем. Я на C++ пишу.»
В каком же простите месте? Самым слабым местом всегда является скорость считывания с диска, а посчитать мд5 хеш (хотя что-то слабо верится что именно по хешу сравнение, а не по шаблонам) и найти в списке сигнатур (пусть даже среди нескольких миллионов) хеш-поиском (да хоть бинарным) — вопрос нескольких долей миллисекунды.
2. потому что хеш таблица хорошо работает, только если она слабо заполнена (<30%), что в случае 5.7 миллионов элементов (*8 байт) требует больше памяти, чем есть на моей видяхе. А по первым результатам хеш-поиск на основном ядре при оптимальных параметрах сливает бинарному на видеокарте.
3. ну это и не «мой метод», просто разновидность частотного анализа, немного упрощенная для эффективной реализации.
зато теперь можно увидеть какие пароли точно нельзя считать надежными.
А для усеченного md5 хеша могут действовать другие правила, нежели для полного, опять же, доказательство идентичности свойств отсутствует.
Так что не уверен, когда я генерил таблицы для MD5 с фиксированной функцией редукции и цепочкой длины 10000 — было жуткое количество коллизий при наборе символов сравнимом по мощности с разрядностью хеш-значения.
Но я и обратного утверждать не буду :)
Не стоит на это закладываться. Но да, массовый перебор будет соответственно в миллион раз медленнее — и на ближайшие пару лет взломщиков это остановит.
Но да, нагрузка на сервер при этом возрастает ужасно, и для высоконагруженного решения — идея не приемлема.
Пароль + соль, а лучше сразу bcrypt — значительно надежнее/удобнее.
если предположить, что никакого доступа к ним невозможно, то да, лимитирование, очевидно будет плюсом к защите.
40кб таскать в веб-форме, думаю, допустимо.