Вы знаете, если сайт позволяет такие махинации, то на этот фишинг поведусь и я, хотя я себя считаю «продвинутым пользователем». Потому как банально забиваются «левые» параметры и этот param оказывается за гранью традиционного поля ввода.
Возможно я прочитал статью «поперек», но ведь да, у каждого устройства свой персональный ключ, потому при отправке imessage уходит не одно сообщение, а по сообщению на каждый девайс получателя.
YCM учитывает контекст только в текущем компилируемом юните. Т.е. он может найти определение во включенном хедере, но не перейдет от одной имплементации к другой.
С одной из самых лучших корпоративных страховок (судя по сайту страховой) я все равно выкладываю 30-50% счета за врача из своего кармана. Другой вопрос уже что это суммы до 100 евро, которые сопоставимы (были сопоставимы) с хорошими клиниками на Украине. Европа разная, и медицина в ней тоже разная.
Находил пару ошибок у TI в библиотеке периферии, где была проблема с инициализацией UART если до этого были «неожиданные» махинации с клокингом. Вообще код драйверов периферии хоть зачастую и не тривиален, но его можно прочитать и понять за разумное время.
В Reference manual к МК STM32F407 про NVIC почти нет информации. Но есть ссылка на отдельный документ
— чем больше долбаюсь с ST, тем меньше понимаю за что их любят то. У TI мануалы шикарные. У NXP они весьма неплохие. У Freescale адский ад с форматированием, но все собрано в кучу и достаточно структурированно. А у ST приходится тасовать вагон PDF'ок между всеми мониторами и еще не забывать что куда ссылается. Единственное что STM32F4Discovery как-то стала массовой бордой, да и функционально на ней куча всего, потому что в свете mbed это как-то не выглядит конкурентным преимуществом.
Я не могу сказать, что не разделяю такой взгляд, но последнее время я нахожу намного более эффективным просто контроллировать работу себя и компилятора. В основном я ковыряюсь с разными микрухами на С++ (а сейчас — и на rust), и писать высокоуровневые конструкции, а потом, при необходимости, проверять ассемблерный листинг таки занимает меньше времени чем писать на ассемблере всё.
Естественно останутся неудачные места, например у моих программ в шапке вот такой кусок:
где сравнение очевидно не имеет смысла. Проблемный код появился из-за того, что эти числовые константы разрешаются уже на этапе компоновки, когда поздно выпиливать ненужный код.
Кстати ассемблерный листинг читать «как есть» тоже сейчас не обязательно, благо неплохие дизассемблеры и декомпиляторы можно найти и не имея бюджета на всякий HexRays :-)
Вы знаете, в компиляторах задача распихать все что можно по регистрам занимает нетривиальный кусок кода, потому что это сложно. И в большинстве случаев компиляторы запихивают в регистры всё что можно.
Как пример — у меня тут ~2000 строк кода на rust, со структурами, методами, локальными переменными в методах. В выходном листинге стек не используется вообще. И .rodata/.data пустые тоже. LLVM иногда похож на магию.
Продолжайте конечно, тема интересная и весьма широкая. еще интересно бы почитать про сравнение шедулеров в популярных ОС (в т.ч. всяких «мелких» RTOS).
А разве user namespace появился не несколько раньше?
> у всех конетйнеров он системный с кучей лишней информации о соседях
общая информация — та, которая относится к хосту, cmdline, device tree, irq, прочее. Соседние PIDы в proc не видно.
а не наоборот?
А еще у программистов большая и дружная команда «поддержки на продакшене», с которой как-то веселее работается.
— чем больше долбаюсь с ST, тем меньше понимаю за что их любят то. У TI мануалы шикарные. У NXP они весьма неплохие. У Freescale адский ад с форматированием, но все собрано в кучу и достаточно структурированно. А у ST приходится тасовать вагон PDF'ок между всеми мониторами и еще не забывать что куда ссылается. Единственное что STM32F4Discovery как-то стала массовой бордой, да и функционально на ней куча всего, потому что в свете mbed это как-то не выглядит конкурентным преимуществом.
Естественно останутся неудачные места, например у моих программ в шапке вот такой кусок:
где сравнение очевидно не имеет смысла. Проблемный код появился из-за того, что эти числовые константы разрешаются уже на этапе компоновки, когда поздно выпиливать ненужный код.
Кстати ассемблерный листинг читать «как есть» тоже сейчас не обязательно, благо неплохие дизассемблеры и декомпиляторы можно найти и не имея бюджета на всякий HexRays :-)
Как пример — у меня тут ~2000 строк кода на rust, со структурами, методами, локальными переменными в методах. В выходном листинге стек не используется вообще. И .rodata/.data пустые тоже. LLVM иногда похож на магию.