Сильно затруднить перебор можно при помощи специализированного хеширования, например тот же Argon2. Тут хоть алгоритм шифрования и известен, но ресурсов требует неразумно много для эффективного брутфорса, как ни крути.
Но ведь конкретно в этом случае из цикла на второй строчке. Они не могут быть равны.
А для алгоритима из статьи лишнее условие совсем не нужно, оно лишь впустую его усложнит, как мне думается (всё равно никто же не собирается использовать его?).
Кажется, что благодаря колабу значительно выросло количество интересных туториалов для ML и в целом снизился порог входа. А значит число потенциальных специалистов больше, всевозможные библиотеки используются и развиваются активнее, гуглу проще нанять опытного человека себе в команду.
Основные случаи (derive из std и serde) плагины давно умеют обрабатывать специально и просто понимают что трейт как-то реализуется. Для более сложных случаев есть возможность экспериментально раскрывать proc-macro, но это работает не всегда и не совсем стабильно.
Исследователь раскрыл уязвимость, которая может вывести из строя любой iPhone, а Apple так и не исправила: если забыть устройство на краю стола, то котик может его уронить и разбить. Пенсионер забыл устройство на краю + имеет достаточно твердый пол + толика невезения — и даже сброс настроек не поможет.
Действительно, это уже нельзя легко исправить, но «уязвимости» одного уровня — из-за череды нелепых случайностей устройство теряет работоспособность. Утечек данных нет, происходит такое событие редко.
Если организатор знает пары, то что ему мешает воспользоваться самым первым способом и генерировать случайные пары до тех пор, пока всё не станет хорошо? А потом их просто разослать. Во-вторых, каким образом предлагается рассылать случайное число от участникам в день розыгрыша, если у них нет интернета? Видимо письмом. Наконец, схема «получи один огромный лист, а затем получи второй с числом, чтобы выбрать человека с первого листа» кажется несколько избыточной и гораздо более склонной к ошибкам (особенно для пожилых участников).
Гугл говорит, что в креветках 99кал/100гр., а масса одной щелкающей — 25 грамм. Будем считать, что щелкнуть они могут пять раз подряд, и в одной креветке находится 25 калорий энергии. Значит за раз она может нагреть 1 грамм воды на 5 градусов. Хотим нагреть на 4400 градусов, получим что-то около 1.1 миллиграмм воды.
Прикидка очень-очень грубая, я бы порядок-два скинул, но в целом как-то так.
Правильно ли я понимаю, что новость заключается лишь в том, что PCIe-совместимое устройство воткнули в PCIe-слот? Оно успешно опозналось, но дальше видеокарта не заработала и ничего не произошло, так?
Раст тут не при чем. Практически для любого популярного языка существует компилятор и какой-нибудь умный линтер. Опять же, практика запрета предупреждений применяется много где, Раст здесь не привнес ничего нового.
ИМХО, в нем просто-напросто, из-за некоторых проблем с IDE, довольно часто приходится читать вывод компилятора, а там предупреждения сильно мозолят глаза. Ну и практически нету легаси, из-за молодости языка.
Здесь вообще-то не обычная обфускация/минификация. Здесь генерация шрифтов, чтобы текст в html не соответствовал отображаемому. И это, очевидно, мешает парсингу данных.
Потому что с одной стороны, насколько мне известно, такого механизма для гугл документов реализовано ещё не было — не нужно было. С другой стороны, бумажка-то уже есть и действовать нужно сейчас. РКН не будет ждать пока где-то в недрах гугла разработают и отладят новый функционал. Тупо проще удалить.
Потому что лучше сказать, что "компилятор выдает только корректный результат компиляции".
По вашей ссылке большая часть проблем — какие-то краши компилятора, медленная работа, нестабильные (сырые) фичи и ещё тысяча вещей. Обычно компилятор просто не выдает программу в таком случае.
Гораздо лучше смотреть на приоритеты. Получается отношение open/closed такое: P-high: 88/945, P-critical: 1/75. Уже гораздо выглядит, причем их них I-unsound только 21/80, а единственная открытая critical про то, что некоторый код вдруг перестал компилироваться на бета-ветке.
Не говорю, что это идеально, но уже гораздо ближе к правде, чем страшные 2729/5645.
И утечки памяти Rust не находит. Они не приводят к UB, так что с точки зрения языка в этом ничего страшного нет. Можно легко получить утечку при помощи метода Box::leak, ну или просто создав цикл из RefCount
Если в двигатель заливается только жидкий кислород и жидкий водород, то получить что-то кроме воды — задачка не из лёгких. New Shepard, если я правильно читать википедию, ничего другого и не содержит.
Не понял аналогии, возможно вы что-то путаете. В языке есть let mut/let и есть &mut/ & (ссылки). Если планируется менять переменную, то let mut нужно обязательно указывать, хотя компилятор и так мог бы разобраться. Эта пометка лишь помогает понять человеку, меняется ли значение. При желании, можно всем переменным ставить mut и ничего не сломается. С ссылками дела обстоят немного интереснее, потому что язык требуют от программиста соблюдать некоторые правила.
Они формулируются как-то так: на каждый объект может существовать либо единственная &mut ссылка, либо сколько угодно не-mut. Либо то, либо другое — одновременно нельзя.
Зачем это нужно? В основном, чтобы обеспечивать спокойствие программиста в многопоточных приложениях. С одной стороны, в программе ни один объект не изменяется одновременно из двух мест, а значит не бывает гонок. Вдобавок никто не может наблюдать промежуточное состояние, когда объект изменился только частично и находится в некорректном состоянии.
Эти ограничения могут казаться излишне жёсткими, но на самом деле всё не так плохо. Во-первых, очень часто не нужно менять существующие объекты, достаточно их только читать. Во-вторых, некоторые вещи, например подкючение к БД, можно использовать и по обычной ссылке, несмотря что происходят всякие INSERT INTO и состояние "меняется" — базы данных сами умеют разруливать гонки и им не нужна помощь от компилятора. В-третьих, всегда можно перенести проверки в runtime, используя Arc+Mutex. Они не позволят нарушить правила и сделать гонку данных, но при этом позволяют (плохо) писать практически как на обычных языках.
Простой пример без многопоточности: человек начал итерировать по стандартному списку (vector), для чего взял на него не-mut ссылку. В большинстве других языков, если вдруг кто-то добавит элемент в список, то произойдет либо UB, либо исключение, либо какая-то другая неожиданность. Но чтобы добавлять элементы в список необходимо иметь &mut ссылку на вектор, а компилятор этого не позволит, совсем. Вот таким нехитрым образом потенциальная ошибка нашлась сразу же.
Константы ≠ иммутабельные переменные. Константное значение может быть (и будет) вычислено в compile-time и жёстко зашито в бинарник. Если мы спрашиваем число у пользователя и кладём в переменную, то она не может быть const. Даже если никогда не собираемся её обновлять. Невозможно захардкодить значение, которого мы не знаем.
Так что кодеру приходится думать о том, что и где у нас мутирует и почему
Весь язык построен на borrowing rules, которые требуют, чтобы на один объект не было больше одной мутабельной ссылки в каждый момент времени. Это довольно строгое ограничение, которое компилятор должен суметь доказать в compile-time. Соответственно думать и помнить об этом приходится, таков язык. Он вообще не позиционируется как простой.
Должна быть поддержка utf8/utf16 с определением длины таких строк в символах.
Обычный вопрос для юникода — а что именно считать одним символом? Не все знакомы с особенностями юникода, поэтому в corner-cases ожидания людей частенько не совпадают с реальным поведением. Соответственно вылезают неожиданные баги, которые язык стремится предотвратить. Явное лучше неявного и всё такое. Однако для простых случев в стандартной библиотеки есть s.chars(), но у него в документации явно сказано, что он может возвращать не совсем что хотелось. Плюс в Книге целая глава посвящена аккуратной работе со строками.
Следующий момент — Rust позиционируется как производительный язык с zero-cost абстракциями. Вычислить длину UTF8 строки невозможно за O(1). Это совсем не совпадает с ожиданием, что длина любой коллекции вычисляется быстро. Поэтому предлагается писать s.chars().count() — явно создать итератор по символам, полностью его перебрать и вычислить длину.
Сильно затруднить перебор можно при помощи специализированного хеширования, например тот же Argon2. Тут хоть алгоритм шифрования и известен, но ресурсов требует неразумно много для эффективного брутфорса, как ни крути.
Но ведь конкретно в этом случае
из цикла на второй строчке. Они не могут быть равны.
А для алгоритима из статьи лишнее условие совсем не нужно, оно лишь впустую его усложнит, как мне думается (всё равно никто же не собирается использовать его?).
Кажется, что благодаря колабу значительно выросло количество интересных туториалов для ML и в целом снизился порог входа. А значит число потенциальных специалистов больше, всевозможные библиотеки используются и развиваются активнее, гуглу проще нанять опытного человека себе в команду.
Интересно, что в приложении существует похожая фича: отображение комментариев, соответствующих текущему участку видео
Скриншот
Основные случаи (derive из std и serde) плагины давно умеют обрабатывать специально и просто понимают что трейт как-то реализуется. Для более сложных случаев есть возможность экспериментально раскрывать proc-macro, но это работает не всегда и не совсем стабильно.
Исследователь раскрыл уязвимость, которая может вывести из строя любой iPhone, а Apple так и не исправила: если забыть устройство на краю стола, то котик может его уронить и разбить. Пенсионер забыл устройство на краю + имеет достаточно твердый пол + толика невезения — и даже сброс настроек не поможет.
Действительно, это уже нельзя легко исправить, но «уязвимости» одного уровня — из-за череды нелепых случайностей устройство теряет работоспособность. Утечек данных нет, происходит такое событие редко.
А почему не докер? Сама статья как раз про это ведь. От себя добавлю, что в такой ситуации ради эксперимента ставил docker-mailserver, всё работало.
Если организатор знает пары, то что ему мешает воспользоваться самым первым способом и генерировать случайные пары до тех пор, пока всё не станет хорошо? А потом их просто разослать. Во-вторых, каким образом предлагается рассылать случайное число от участникам в день розыгрыша, если у них нет интернета? Видимо письмом. Наконец, схема «получи один огромный лист, а затем получи второй с числом, чтобы выбрать человека с первого листа» кажется несколько избыточной и гораздо более склонной к ошибкам (особенно для пожилых участников).
Гугл говорит, что в креветках 99кал/100гр., а масса одной щелкающей — 25 грамм. Будем считать, что щелкнуть они могут пять раз подряд, и в одной креветке находится 25 калорий энергии. Значит за раз она может нагреть 1 грамм воды на 5 градусов. Хотим нагреть на 4400 градусов, получим что-то около 1.1 миллиграмм воды.
Прикидка очень-очень грубая, я бы порядок-два скинул, но в целом как-то так.
Правильно ли я понимаю, что новость заключается лишь в том, что PCIe-совместимое устройство воткнули в PCIe-слот? Оно успешно опозналось, но дальше видеокарта не заработала и ничего не произошло, так?
Раст тут не при чем. Практически для любого популярного языка существует компилятор и какой-нибудь умный линтер. Опять же, практика запрета предупреждений применяется много где, Раст здесь не привнес ничего нового.
ИМХО, в нем просто-напросто, из-за некоторых проблем с IDE, довольно часто приходится читать вывод компилятора, а там предупреждения сильно мозолят глаза. Ну и практически нету легаси, из-за молодости языка.
Здесь вообще-то не обычная обфускация/минификация. Здесь генерация шрифтов, чтобы текст в html не соответствовал отображаемому. И это, очевидно, мешает парсингу данных.
Потому что с одной стороны, насколько мне известно, такого механизма для гугл документов реализовано ещё не было — не нужно было. С другой стороны, бумажка-то уже есть и действовать нужно сейчас. РКН не будет ждать пока где-то в недрах гугла разработают и отладят новый функционал. Тупо проще удалить.
Потому что лучше сказать, что "компилятор выдает только корректный результат компиляции".
По вашей ссылке большая часть проблем — какие-то краши компилятора, медленная работа, нестабильные (сырые) фичи и ещё тысяча вещей. Обычно компилятор просто не выдает программу в таком случае.
Гораздо лучше смотреть на приоритеты. Получается отношение open/closed такое: P-high: 88/945, P-critical: 1/75. Уже гораздо выглядит, причем их них I-unsound только 21/80, а единственная открытая critical про то, что некоторый код вдруг перестал компилироваться на бета-ветке.
Не говорю, что это идеально, но уже гораздо ближе к правде, чем страшные 2729/5645.
И утечки памяти Rust не находит. Они не приводят к UB, так что с точки зрения языка в этом ничего страшного нет. Можно легко получить утечку при помощи метода
Box::leak, ну или просто создав цикл изRefCountЕсли в двигатель заливается только жидкий кислород и жидкий водород, то получить что-то кроме воды — задачка не из лёгких. New Shepard, если я правильно читать википедию, ничего другого и не содержит.
Размер распаковщика обычно учитывается в весе архива. Так что здесь всё хорошо.
Это сокращение от "Симпл Сторадж Сервис", видимо.
Не понял аналогии, возможно вы что-то путаете. В языке есть
let mut/letи есть&mut/&(ссылки). Если планируется менять переменную, тоlet mutнужно обязательно указывать, хотя компилятор и так мог бы разобраться. Эта пометка лишь помогает понять человеку, меняется ли значение. При желании, можно всем переменным ставить mut и ничего не сломается. С ссылками дела обстоят немного интереснее, потому что язык требуют от программиста соблюдать некоторые правила.Они формулируются как-то так: на каждый объект может существовать либо единственная &mut ссылка, либо сколько угодно не-mut. Либо то, либо другое — одновременно нельзя.
Зачем это нужно? В основном, чтобы обеспечивать спокойствие программиста в многопоточных приложениях. С одной стороны, в программе ни один объект не изменяется одновременно из двух мест, а значит не бывает гонок. Вдобавок никто не может наблюдать промежуточное состояние, когда объект изменился только частично и находится в некорректном состоянии.
Эти ограничения могут казаться излишне жёсткими, но на самом деле всё не так плохо. Во-первых, очень часто не нужно менять существующие объекты, достаточно их только читать. Во-вторых, некоторые вещи, например подкючение к БД, можно использовать и по обычной ссылке, несмотря что происходят всякие INSERT INTO и состояние "меняется" — базы данных сами умеют разруливать гонки и им не нужна помощь от компилятора. В-третьих, всегда можно перенести проверки в runtime, используя Arc+Mutex. Они не позволят нарушить правила и сделать гонку данных, но при этом позволяют (плохо) писать практически как на обычных языках.
Простой пример без многопоточности: человек начал итерировать по стандартному списку (vector), для чего взял на него не-mut ссылку. В большинстве других языков, если вдруг кто-то добавит элемент в список, то произойдет либо UB, либо исключение, либо какая-то другая неожиданность. Но чтобы добавлять элементы в список необходимо иметь &mut ссылку на вектор, а компилятор этого не позволит, совсем. Вот таким нехитрым образом потенциальная ошибка нашлась сразу же.
Константы ≠ иммутабельные переменные. Константное значение может быть (и будет) вычислено в compile-time и жёстко зашито в бинарник. Если мы спрашиваем число у пользователя и кладём в переменную, то она не может быть const. Даже если никогда не собираемся её обновлять. Невозможно захардкодить значение, которого мы не знаем.
Весь язык построен на borrowing rules, которые требуют, чтобы на один объект не было больше одной мутабельной ссылки в каждый момент времени. Это довольно строгое ограничение, которое компилятор должен суметь доказать в compile-time. Соответственно думать и помнить об этом приходится, таков язык. Он вообще не позиционируется как простой.
Обычный вопрос для юникода — а что именно считать одним символом? Не все знакомы с особенностями юникода, поэтому в corner-cases ожидания людей частенько не совпадают с реальным поведением. Соответственно вылезают неожиданные баги, которые язык стремится предотвратить. Явное лучше неявного и всё такое. Однако для простых случев в стандартной библиотеки есть
s.chars(), но у него в документации явно сказано, что он может возвращать не совсем что хотелось. Плюс в Книге целая глава посвящена аккуратной работе со строками.Следующий момент — Rust позиционируется как производительный язык с zero-cost абстракциями. Вычислить длину UTF8 строки невозможно за O(1). Это совсем не совпадает с ожиданием, что длина любой коллекции вычисляется быстро. Поэтому предлагается писать
s.chars().count()— явно создать итератор по символам, полностью его перебрать и вычислить длину.