Как стать автором
Обновить
162
0
gurux13 @gurux13

SWE

Отправить сообщение
Недавно проходил хакатон DeepHack. Мы в нем участвовали и вынесли для себя понимание, что результаты получаются труднопредсказуемыми без эксперимента. То есть, были какие-то мысли, которые в теории должны были давать большой прирост, но по факту не давали ничего, а иногда ухудшали поведение. Были примитивные идеи, которые попробовали просто потому, что легко сделать, и внезапно они дали хороший прирост.
Комментарии? Их есть у меня.
  1. Каждое создание функции приводит к линейному поиску среди списка модулей. unordred_map?
  2. Кажется, это всё не потокобезопасно
  3. По процедуре нельзя получить её модуль. Это не даёт возможности управлять вызовами LoadLibrary/FreeLibrary, а это может быть важно.
  4. FreeLibrary очень уж далеко от LoadLibrary
  5. Почему-то, если FreeLibrary упало, то assert(), а LoadLibrary проверяется, судя по всему, в момент вызова процедуры. Если LoadLibrary вернул NULL, получится вызов нулевого указателя. Это не UB, случаем?


А в целом — идея интересная, особенно оператор приведения типа — в голову такое не приходило.
Меня больше всего раздражает даже не подтверждение email, а необходимость его дважды вводить. А потом всё равно подтверждать!
Мне кажется, у большинства пользователей стоит автозаполнение поля email (мне хром автоматом подсказывает, хотя я это не настраивал). Но только, черт побери, для первого поля ввода email, для поля «повторите ввод email» приходится делать copy-paste.

И вопрос — нет ли у вас статистики о том, сколько email не было подтверждено никогда (которые можно считать ошибочными)? Это, конечно, имеет смысл только для ресурсов с политикой типа (1) проверка обязательна, пока пользователь не подтвердит e-mail ничего делать нельзя. Для второй политики не так интересно, но тоже может быть полезно.

Спасибо за интересную статистику и статью!
А ядра синхронные? То есть, если написать
mov up, left
mov up, down
А дальше снова объединить потоки данных, они придут синхронно?
World War Z, если не ошибаюсь.
//Даа, что-то я слоупок…
Причем это длинная история
Коммит, который крешил аппарат 1го апреля (видимо, случайно)
Здесь сатурация начинала уплывать (правда, если нажать «тест»)
А если почитать changeset этого a1ex, становится видно, что он убрал плохую шутку и заменил её менее плохой. Недостаточно разбираюсь в коде прошивки, но кажется, что 1го апреля с вероятностью 30% происходила «игра» с яркостью дисплея: он или мигал до произвольной яркости с вероятностью 99%, либо гас насовсем с вероятностью 1%. Это происходило либо с некоторым периодом (2 секунды), либо когда запись активна.

Мне кажется, за такое надо не только руки отрывать. В текущем варианте не сильно лучше, конечно.
Визуальное программирование под андроид. Кажется, я видел всё в этой жизни.
Железная часть позволяет измерять напряжение на аккумуляторе, правда, не очень точно. Полагаю, что переписать код так, чтобы напряжение учитывалось в подсчете емкости, несложно. Я сам делал похожую штуку для слежения за разрядом литий-ионных аккумуляторов, и учитывал напряжение — график весьма нелинейный.
Найти ВАХ лампочки тоже не очень сложно, из этого можно вычислить более-менее точную емкость.

А вообще, если в это дело еще и амперметр засунуть, будет совсем здорово.
Диапазон читается как
(0xffffffff-MAX_ERRNO+1; 0xffffffff)
Левое число меньше 2^32.
Неплохо было бы таки написать, что выведет приведенный код, и как добиться разных output'ов.
Та самая статья, похоже, на web.archive.org сохранена отлично: web.archive.org
Спасибо за статью!
Мне кажется, что использование FASM в C# коде — это как кондиционер на велосипеде. Ну или велосипед на кондиционере. Да и вообще, внедрение в нативный код на C#, без DLLки, которую можно инжектить и спокойно вызывать (чтобы можно было хотя бы на С писать, а не на асме), странно.
Интересно было бы посмотреть на вызов C# кода из внедренного кода, хотя это, кажется, из области фантастики.

И еще,
нужно предусмотреть очередь, для этого я и использовал 80 байт размер, как его реализовать, подумайте сами
не понял фразу.
Что можно запустить, можно сломать. Или гомоморфное шифрование для RSA или чем там подписано?
Могу ошибаться, но слышал, что бывают ситуации, когда ядро использует стек юзерспейс-программы. Интересно было бы про это почитать.
iPhone не блокируется на железном уровне (как macbook, например, с его паролем efi).
Все, что нужно знать для разблокировки — данные учетной записи, с которой была произведена блокировка.
Поддержка apple удостоверяется в том, что именно Вы хозяин учетной записи, находит ее и перевязывает обратно на Вас.
После этого Вы имеете возможность восстановить аппарат самостоятельно. Правда, все данные с него будут стерты.
— промахнулся веткой
Пожалуйста, прочитайте первую строку этой (моей) статьи.
Фишинг, троян, утечки из Яндекса. У злоумышленника был пароль от учетки Яндекс в открытом виде, они сбросили пароль на учетку Apple через почту на Яндексе.
У нас не было никакой статистики о том, какие пароли ставят злоумышленники. Поэтому, строго говоря, все стратегии равнозначны. Однако, в предположении о том, что злоумышленники стараются сделать трудноподбираемый пароль, рандомизация позволяет обойти это и сделать мат. ожидание времени поиска пароля ровно половиной общего количества паролей.

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность