А как вы разбираетесь с проблемами, когда появляются серверы, по которым от вендора есть информация, что поддерживаются только дистрибутивы А, Б, В, и ядра 1,2,3? Вот по вашим же слайдам, у вас есть много машин с 4.x ядром, вероятно, это более старое железо и наверняка среди них есть те, по которым вендор не может дать поддержку, что на 5.х ядрах не будет проблем.
Абсолютно согласен. Ни один из даташитов не указывает производительность control plane свича, и такая история не только у наших вендоров. Перегрузил CPU свича контролплейном -- и он перестает быть управляемым свичом и теряет половину функций безопасности.
Как бы то ни было, но наши - догоняющие и обладают гораздо меньше инженерными ресурсами, поэтому фичи и баги имеют приоритет при разработе, а увеличение производительности, упрощение траблшутинга, безопасность - это все важно, но имеет гораздо меньший приоритет. Это не значит, что наши железки плохие, это лишь означает, что комьюнити у них мизерный, а такие ограничения весьма нетривиально обнаружить и отдиагностировать за пределами лабы.
А меня наоборот привлекают безмоторные транспортные средства. С мощным мотором нужно искать подходящую трассу для покатушек. Такой технике просто не место ни в парке ни на тротуаре. И для окружающих опасно и забота об их безопасности убивает все удовольствие от езды. Подходяшая трасса будет загородом, и нужно дополнительное время, чтобы добраться. Покатушки надо планировать и выделять под это существенное время. А чем сложнее планирование, тем реже катаешься.
С мелким электрическим мотором получается другая картина — удобно хранить дома, удобно перемещаться по городу, но фана от поездки просто 0. Это просто транспорт добраться из точки А в точку Б. Именно такую роль у нас выполняет дома электросамокат — мобильный транспорт на небольшие дистанции, когда не нужна машина.
А вот там, где никакого двигателя нет — только мускульная сила райдера, там настоящий фан. Нужно просто найти то средство передвижения и тот стиль катания, который нравится лично тебе. Я сам в прошлом году впервые встал на доску, на лонгборд. Временами было прикольно, но чаще не очень — просто круизить скучно — вот и катался мало. В этом году поменял на серфскейт, взял подходящую обувь и защиту — и понял, что вот мой траспорт для фана. Хочешь — просто нарезаешь дуги по асфальту и кайфуешь от ощущения того, что гладкий асфальт исчез и вместо него теперь живые волны. Хочешь — упражняешься в мастерстве крутых поворотов на пятачке. Хочешь — едешь в скейтпарк и пробуешь кататься на рампе. А то, что можно заезжать в горку, разгоняться и тормозить не снимая ног с доски — вообще удивительное свойство.
Айтишнику совершенно не обязательно кататься на чем-то умном или хитродвигательном, пошевелить ручками-ножками подальше от офисного кресла тоже полезно. И весело.
Ага, и у меня есть. Это не эффекты коррекции, как то же гало в первые дни, а что-то типа эффекта памяти на сетчатке. Было и до коррекции. Смотришь на светящиеся буквы на темном фоне, закрываешь глаза, а цветные строки еще несколько секунд висят, но уже в виде цветных полос, буквы уже неразличимы. Ночью это мешает чтению с темного фона — вся страница рябит. Днем же "спецэффекты" пропадают. Со светлыми темами (черный на белом) такого эффекта нет.
Несколько удручает, что мир взял моду на темные темы, а светлые готовятся по остаточному принципу и не дотягивают по качеству.
Таких итераций требуется несколько, 5-6. Разрезанное на печенюхи тесто занимает больше места, а партия печется обычно быстрее, чем раскатываешь и вырезаешь новую. В итоге долго муторно и жарко (степень зависит от духовки).
А вот такие тесселированные елочки — это быстро и прикольнее, чем банальные квадраты. Создают чуточку больше настроения. Еще есть скалки с готовым паттерном для печенюх, которые надо разрезать, там рельефный паттерн должен сгладить "скучность" правильных форм. Но это уже другое решение той же проблемы.
Как правильно уже заметили, не надо быть супер-гуру для разработки в ядре. Но свои особенности есть. Ровно те же, что и в любой системной и низкоуровневой разработке. Самое главное в том, что тут нельзя падать и портить память. Нельзя надеяться, что при падении нагрузка уйдет на резервную ноду, а упавшая быстро перезапустится. Креш, дедлок, stall в ядре распространяется на всю систему, и встанет все. Этого не нужно бояться, просто стратегия "падаем в случае отказов" неприменима.
Мне с Python там делать нечего?
Если позанудствовать, то вообще-то можно писать свои модули для ядра на разных языках. Был проект для запуска скриптовых языков в ядре, например того же питона, но я не знаю, насколько он живой сейчас. Есть и исследования о возможности использования скриптов в ядре, например lua.
Но это все более специализированные случаи, у которых есть своя какая-то особая цель. А так вам нужен С. В ядре диалект 89 года, щедро приправленный gnu-расширениями, своя реализация libc. Но никакого C++. И это дает очень интересный эффект, с одной стороны порог входя в ядро высокий просто из-за его специфики, с другой стороны С — самый простой низкоуровневый язык, в нем нет каких-то вычурных конструкций, нет скрытого смысла за операциями, и он придерживает планку входа.
Если вы хотите посвятить себя системной разработке, то вы просто вынуждены изучить С, знать как его использовать и как отстрелить себе что-нибудь. Сейчас есть языки, где можно писать код безопаснее и не менее эффективно, тот же C++ или Rust, но 90% системного ПО уже написана и в большинстве своем там именно C. Его придется читать, понимать и изредка патчить.
реально ли получать деньги за разработку и поддержку Linux?
Реально. Но сложно, просто потому, что системной разработкой занимается кратно меньше компаний, чем тем же вебом. Именно в ядро лезут еще меньше компаний. Но они есть. И это не только гиганты вроде RedHat/Suse/Intel/AMD/Mellanox/FaceBook/etc. Но и мелкие компании тоже есть, одна из самых известных — bootlin, даже некоторые хостеры тоже ввязываются в разработку ядра. Работы больше чем кажется, но ее сложно отыскать.
Кстати, раз упомянул про Bootlin, очень советую их материалы и лабы для обучения разработке.
Про debugging секцию хотелось бы добавить. Пугать ядро во время разработки — совершенно нормальное явление, но ядро падает целиком и остается только лог в консоли. Не всегда это удобно и не всегда этого достаточно. Зато есть просто прекрасные утилиты kdump и crash. Первая позволяет создать крашдамп, вторая — его проанализировать.
kdump настраивается один раз, но за него приходится платить некоторым количеством зарезервированной оперативки для хранения второго экземпляра ядра в памяти. Зато по наступлении креша дамп будет собран и система перезагрузится. Это полезно не только во время тестирования в виртуалке, но и при прогоне тестов на CI и в продакшене, когда сложно сказать, что именно триггернуло ошибку.
crash — утилита с набором команд, похожим на gdb.
Так вот, чтобы понять, в каком месте функции произошла ошибка, достаточно запустить дебагер с подгруженным в него модулем
Тоже самое можно сделать при помощи утилиты addr2line.
Авторизация по ключам же, и не нужно вот этого всего хранения паролей в открытом виде в куче скриптов. См. ssh-copy-id и ~/.ssh/authorized_keys. Еще и серверы от брутфорса пароля будут защищены.
Один раз создал ssh-ключ, раскидал публичный ключ на все нужные серверы и никаких проблем с авторизацией. Если ssh-ключ с паролем, то его достаточно разблокировать единожды, многие DE имеют keyring и ключик надо разблокировать только при первом использовании.
У нас анонсировали, что как в Москве будет. И сообщить будет легко и штраф будет неотвратимо приходить. Но в итоге только десяток адресов электронной почты районных комиссий, которые пришлось выискивать по новостным статьям, с которых даже не отвечают.
У нас в городе ввели региональные штрафы за парковку на газоне и сделали возможность сообщить о нарушении. Если бы это работало… В прошлом году я пол лета отправлял материалы в комиссию, но был ли от этого прок? Чиновники ответили мне только раз и то прислали участкового и попросили написать объяснительную, почему мне мешает чужая машина на газоне у меня перед подъездом.
Защита от DDoS тоже бывает разная. И все под ней понимают что-то свое. Кто-то просто блочит те ip, трафик которых преодолевает какие-то границы. Кто-то использует репутационные базы ip-адресов. Кто-то детектирует распространенные атаки с усилением трафика. Кто-то строит модель взаимодействия с защищаемым сервисом и при помощи машинного обучения и определяет, что является нормальным трафиком для сервиса, а что — нет. Чаще всего непонятно, что означает эта самая anti-DDoS, за которую надо доплачивать.
Кэширование HTTP трафика, отбрасывание злонамеренного HTTP, рейт-лимиты на количество запросов, JavaScript-проверки браузера, балансировка нагрузки — любое заглядывание anti-DDoS сервера внутрь HTTP тоже может быть стратегией DDoS защиты. Только это уже не L4, а L7 защита. Любой CDN, любой хостер, которые предлагают такую защиту будет терминировать у себя TLS и заглядывать внутрь HTTPS.
Просто так ругать Cloudflare за чтение трафика в открытом виде нельзя. Если anti-DDoS хостера не делает то же самое, то просто не предоставляет L7 защиты от DDoS (WAF).
А вообще аргументы о том, что какой-то WAF имеет доступ к открытому трафику имеют смысл только пока вы не доверяете WAF, но доверяете хостеру, контролирующему гипервизор вашего VPS и имеющему физический доступ к железному серверу...
This revealed the headers X-Original-URL and X-Rewrite-URL which override the request's path. I first noticed them affecting targets running Drupal, and digging through Drupal's code revealed that the support for this header comes from the popular PHP framework Symfony, which in turn took the code from Zend. The end result is that a huge number of PHP applications unwittingly support these headers
Печально, когда такие вещи тащат во фреймворки, задействуют по-умолчанию, а потом копируют из одного в другой. С точки зрения разработки http-proxy/waf даже с ходу непонятно, что с такими проблемами делать. И защитить сайты от атак было бы неплохо, и тратить ресурсы на поиск нестандартных и редких заголовков не хочется.
Добавлю подкасты для тех, кто интересуется сетями:
Kernel of Truth — En, ведут его ребята из Cumulus Networks, рассказывают в основном о программной части Linux-networking
Packet Pushers — En, у нсх есть несколько треков, мне больше всего понравился Heavy Networking. Это уже менее специализированный и более разнообразный подкаст.
LinkMeUp — Ru, Если по ссылке выше иногда говорят, что они "best networking podcast ever", то они просто не говорят по-русски и не слушали linkmeup.
Я бы сказал, что лучшие рускоязычные материалы для вхождения в сети — СДСМ, Сети Для Самых Маленьких, by eucariot. Есть тут на хабре и на GitBook. Возможно как раз то, что вы хотели бы видеть — о том как работают сети, как их строить и обслуживать.
Программистам, которые заняты протокольной частью, тоже хорошо подходят — можно читать статьи как вводные, для чего используются некоторые протоколы, что помогают делать, какие задачи решают.
На исчезающе малом количестве материнских плат все-таки можно, в основном — intel nuc. Я тоже сначала печалился, что моя amd железка не умеет в HDMI-CEC, но коди, который заменил почти весь смарт-тв функционал, гораздо удобнее рулится из смартфона, нежели с обычного пульта.
У меня сложилось впечатление, что так много шагов потребовалось, потому что вы мерили не то, что действительно хотели. Хотели померить, какая реализация функции быстрее, а стали мерить все, включая запуск программы. Из-за этого вы очень много боролись с ядром, когда этого не требовалось. Например, копировали файлы в рамдиск, хотя после первого чтения они попадут в файловый кэш и не будут читаться с диска. Искали самый ненагруженный cpu и планировали задачу именно на него и раскидывали с него все остальные существующие userspace процессы на другие cpu — это же сделает планировщик задач при большой нагрузке. И ядро все еще может вытеснить ваш процесс. И если процесс не бездействует, а вы не запускаете другие ресурсоемкие процессы, то вероятность того, что его память будет вытеснена в swap нулевая.
А могли бы просто старым-добрым способом узнать время перед выполнением функции, прогнать ее множество раз, узнать время, рассчитать дельту. Сделать множество таких замеров и взять минимальное значение — тогда получите максимально правдоподобное значение, которое только возможно получить на системе общего назначения.
Иногда действительно есть смысл отобрать у планировщика несколько ядер для ресурсоемких вычислений. И это можно сделать даже так, что и ядерные потоки не будут планироваться на эти ядра — это параметр isolcpus. Тогда ваши задачи не сможет вытеснить никто, даже ядро. Правда, если у вас несколько таких изолированных процессов, то и балансировкой этих процессов между изолированными ядрами никто заниматься не будет.
Однако, интересно использовать этот кейс не только для получения e-mail адресов.
Не совсем понятно, а какой юз кейс вас напугал? То, что вы смогли отследить разработчиков между различными сервисами, используя Gravatar? Разве это проблема? Разработчики сами создали свой публичный профиль (бренд) и продвигают его: участвуют в разработке на github, отвечают на вопросы в stackoverflow и так далее. То есть это изначально публичная сущность, которая должна собирать в кучу виртуальную личность, которая пользуется кучей сервисов. То, что вы зная публичный email разработчика и нашли следы его активности где бы то ни было — это не бага, это фича.
Вот если бы выяснилось, что удалось связать между собой две виртуальные личности, одна из которых — разработчик, а вторая — кот, которые принадлежат одному человеку желающему разделить публичную и личную жизнь, вот тогда это была бы проблема приватности.
А утечка почты через MD5 — конечно неприятно, но это проблема уже Gravatar. Интересно, репортил ли автор проблему им и что они ответили.
А как вы разбираетесь с проблемами, когда появляются серверы, по которым от вендора есть информация, что поддерживаются только дистрибутивы А, Б, В, и ядра 1,2,3? Вот по вашим же слайдам, у вас есть много машин с 4.x ядром, вероятно, это более старое железо и наверняка среди них есть те, по которым вендор не может дать поддержку, что на 5.х ядрах не будет проблем.
Абсолютно согласен. Ни один из даташитов не указывает производительность control plane свича, и такая история не только у наших вендоров. Перегрузил CPU свича контролплейном -- и он перестает быть управляемым свичом и теряет половину функций безопасности.
Как бы то ни было, но наши - догоняющие и обладают гораздо меньше инженерными ресурсами, поэтому фичи и баги имеют приоритет при разработе, а увеличение производительности, упрощение траблшутинга, безопасность - это все важно, но имеет гораздо меньший приоритет. Это не значит, что наши железки плохие, это лишь означает, что комьюнити у них мизерный, а такие ограничения весьма нетривиально обнаружить и отдиагностировать за пределами лабы.
А меня наоборот привлекают безмоторные транспортные средства. С мощным мотором нужно искать подходящую трассу для покатушек. Такой технике просто не место ни в парке ни на тротуаре. И для окружающих опасно и забота об их безопасности убивает все удовольствие от езды. Подходяшая трасса будет загородом, и нужно дополнительное время, чтобы добраться. Покатушки надо планировать и выделять под это существенное время. А чем сложнее планирование, тем реже катаешься.
С мелким электрическим мотором получается другая картина — удобно хранить дома, удобно перемещаться по городу, но фана от поездки просто 0. Это просто транспорт добраться из точки А в точку Б. Именно такую роль у нас выполняет дома электросамокат — мобильный транспорт на небольшие дистанции, когда не нужна машина.
А вот там, где никакого двигателя нет — только мускульная сила райдера, там настоящий фан. Нужно просто найти то средство передвижения и тот стиль катания, который нравится лично тебе. Я сам в прошлом году впервые встал на доску, на лонгборд. Временами было прикольно, но чаще не очень — просто круизить скучно — вот и катался мало. В этом году поменял на серфскейт, взял подходящую обувь и защиту — и понял, что вот мой траспорт для фана. Хочешь — просто нарезаешь дуги по асфальту и кайфуешь от ощущения того, что гладкий асфальт исчез и вместо него теперь живые волны. Хочешь — упражняешься в мастерстве крутых поворотов на пятачке. Хочешь — едешь в скейтпарк и пробуешь кататься на рампе. А то, что можно заезжать в горку, разгоняться и тормозить не снимая ног с доски — вообще удивительное свойство.
Айтишнику совершенно не обязательно кататься на чем-то умном или хитродвигательном, пошевелить ручками-ножками подальше от офисного кресла тоже полезно. И весело.
Ага, и у меня есть. Это не эффекты коррекции, как то же гало в первые дни, а что-то типа эффекта памяти на сетчатке. Было и до коррекции. Смотришь на светящиеся буквы на темном фоне, закрываешь глаза, а цветные строки еще несколько секунд висят, но уже в виде цветных полос, буквы уже неразличимы. Ночью это мешает чтению с темного фона — вся страница рябит. Днем же "спецэффекты" пропадают. Со светлыми темами (черный на белом) такого эффекта нет.
Несколько удручает, что мир взял моду на темные темы, а светлые готовятся по остаточному принципу и не дотягивают по качеству.
Таких итераций требуется несколько, 5-6. Разрезанное на печенюхи тесто занимает больше места, а партия печется обычно быстрее, чем раскатываешь и вырезаешь новую. В итоге долго муторно и жарко (степень зависит от духовки).
А вот такие тесселированные елочки — это быстро и прикольнее, чем банальные квадраты. Создают чуточку больше настроения. Еще есть скалки с готовым паттерном для печенюх, которые надо разрезать, там рельефный паттерн должен сгладить "скучность" правильных форм. Но это уже другое решение той же проблемы.
Спасибо всем огромное! (:
Очень хочется поучаствовать в этом году, но не хватает двух пунктов кармы. Буду благодарен за плюсики (:
Как правильно уже заметили, не надо быть супер-гуру для разработки в ядре. Но свои особенности есть. Ровно те же, что и в любой системной и низкоуровневой разработке. Самое главное в том, что тут нельзя падать и портить память. Нельзя надеяться, что при падении нагрузка уйдет на резервную ноду, а упавшая быстро перезапустится. Креш, дедлок, stall в ядре распространяется на всю систему, и встанет все. Этого не нужно бояться, просто стратегия "падаем в случае отказов" неприменима.
Если позанудствовать, то вообще-то можно писать свои модули для ядра на разных языках. Был проект для запуска скриптовых языков в ядре, например того же питона, но я не знаю, насколько он живой сейчас. Есть и исследования о возможности использования скриптов в ядре, например lua.
Но это все более специализированные случаи, у которых есть своя какая-то особая цель. А так вам нужен С. В ядре диалект 89 года, щедро приправленный gnu-расширениями, своя реализация libc. Но никакого C++. И это дает очень интересный эффект, с одной стороны порог входя в ядро высокий просто из-за его специфики, с другой стороны С — самый простой низкоуровневый язык, в нем нет каких-то вычурных конструкций, нет скрытого смысла за операциями, и он придерживает планку входа.
Если вы хотите посвятить себя системной разработке, то вы просто вынуждены изучить С, знать как его использовать и как отстрелить себе что-нибудь. Сейчас есть языки, где можно писать код безопаснее и не менее эффективно, тот же C++ или Rust, но 90% системного ПО уже написана и в большинстве своем там именно C. Его придется читать, понимать и изредка патчить.
Реально. Но сложно, просто потому, что системной разработкой занимается кратно меньше компаний, чем тем же вебом. Именно в ядро лезут еще меньше компаний. Но они есть. И это не только гиганты вроде RedHat/Suse/Intel/AMD/Mellanox/FaceBook/etc. Но и мелкие компании тоже есть, одна из самых известных — bootlin, даже некоторые хостеры тоже ввязываются в разработку ядра. Работы больше чем кажется, но ее сложно отыскать.
Кстати, раз упомянул про Bootlin, очень советую их материалы и лабы для обучения разработке.
Про debugging секцию хотелось бы добавить. Пугать ядро во время разработки — совершенно нормальное явление, но ядро падает целиком и остается только лог в консоли. Не всегда это удобно и не всегда этого достаточно. Зато есть просто прекрасные утилиты
kdumpиcrash. Первая позволяет создать крашдамп, вторая — его проанализировать.kdumpнастраивается один раз, но за него приходится платить некоторым количеством зарезервированной оперативки для хранения второго экземпляра ядра в памяти. Зато по наступлении креша дамп будет собран и система перезагрузится. Это полезно не только во время тестирования в виртуалке, но и при прогоне тестов на CI и в продакшене, когда сложно сказать, что именно триггернуло ошибку.crash— утилита с набором команд, похожим на gdb.Тоже самое можно сделать при помощи утилиты addr2line.
Авторизация по ключам же, и не нужно вот этого всего хранения паролей в открытом виде в куче скриптов. См.
ssh-copy-idи~/.ssh/authorized_keys. Еще и серверы от брутфорса пароля будут защищены.Один раз создал ssh-ключ, раскидал публичный ключ на все нужные серверы и никаких проблем с авторизацией. Если ssh-ключ с паролем, то его достаточно разблокировать единожды, многие DE имеют keyring и ключик надо разблокировать только при первом использовании.
У нас анонсировали, что как в Москве будет. И сообщить будет легко и штраф будет неотвратимо приходить. Но в итоге только десяток адресов электронной почты районных комиссий, которые пришлось выискивать по новостным статьям, с которых даже не отвечают.
У нас в городе ввели региональные штрафы за парковку на газоне и сделали возможность сообщить о нарушении. Если бы это работало… В прошлом году я пол лета отправлял материалы в комиссию, но был ли от этого прок? Чиновники ответили мне только раз и то прислали участкового и попросили написать объяснительную, почему мне мешает чужая машина на газоне у меня перед подъездом.
Защита от DDoS тоже бывает разная. И все под ней понимают что-то свое. Кто-то просто блочит те ip, трафик которых преодолевает какие-то границы. Кто-то использует репутационные базы ip-адресов. Кто-то детектирует распространенные атаки с усилением трафика. Кто-то строит модель взаимодействия с защищаемым сервисом и при помощи машинного обучения и определяет, что является нормальным трафиком для сервиса, а что — нет. Чаще всего непонятно, что означает эта самая anti-DDoS, за которую надо доплачивать.
Кэширование HTTP трафика, отбрасывание злонамеренного HTTP, рейт-лимиты на количество запросов, JavaScript-проверки браузера, балансировка нагрузки — любое заглядывание anti-DDoS сервера внутрь HTTP тоже может быть стратегией DDoS защиты. Только это уже не L4, а L7 защита. Любой CDN, любой хостер, которые предлагают такую защиту будет терминировать у себя TLS и заглядывать внутрь HTTPS.
Просто так ругать Cloudflare за чтение трафика в открытом виде нельзя. Если anti-DDoS хостера не делает то же самое, то просто не предоставляет L7 защиты от DDoS (WAF).
А вообще аргументы о том, что какой-то WAF имеет доступ к открытому трафику имеют смысл только пока вы не доверяете WAF, но доверяете хостеру, контролирующему гипервизор вашего VPS и имеющему физический доступ к железному серверу...
Пакость какая (: Practical web-cache poisoning:
Печально, когда такие вещи тащат во фреймворки, задействуют по-умолчанию, а потом копируют из одного в другой. С точки зрения разработки http-proxy/waf даже с ходу непонятно, что с такими проблемами делать. И защитить сайты от атак было бы неплохо, и тратить ресурсы на поиск нестандартных и редких заголовков не хочется.
Добавлю подкасты для тех, кто интересуется сетями:
Я бы сказал, что лучшие рускоязычные материалы для вхождения в сети — СДСМ, Сети Для Самых Маленьких, by eucariot. Есть тут на хабре и на GitBook. Возможно как раз то, что вы хотели бы видеть — о том как работают сети, как их строить и обслуживать.
Программистам, которые заняты протокольной частью, тоже хорошо подходят — можно читать статьи как вводные, для чего используются некоторые протоколы, что помогают делать, какие задачи решают.
На исчезающе малом количестве материнских плат все-таки можно, в основном — intel nuc. Я тоже сначала печалился, что моя amd железка не умеет в HDMI-CEC, но коди, который заменил почти весь смарт-тв функционал, гораздо удобнее рулится из смартфона, нежели с обычного пульта.
У меня сложилось впечатление, что так много шагов потребовалось, потому что вы мерили не то, что действительно хотели. Хотели померить, какая реализация функции быстрее, а стали мерить все, включая запуск программы. Из-за этого вы очень много боролись с ядром, когда этого не требовалось. Например, копировали файлы в рамдиск, хотя после первого чтения они попадут в файловый кэш и не будут читаться с диска. Искали самый ненагруженный cpu и планировали задачу именно на него и раскидывали с него все остальные существующие userspace процессы на другие cpu — это же сделает планировщик задач при большой нагрузке. И ядро все еще может вытеснить ваш процесс. И если процесс не бездействует, а вы не запускаете другие ресурсоемкие процессы, то вероятность того, что его память будет вытеснена в swap нулевая.
А могли бы просто старым-добрым способом узнать время перед выполнением функции, прогнать ее множество раз, узнать время, рассчитать дельту. Сделать множество таких замеров и взять минимальное значение — тогда получите максимально правдоподобное значение, которое только возможно получить на системе общего назначения.
Иногда действительно есть смысл отобрать у планировщика несколько ядер для ресурсоемких вычислений. И это можно сделать даже так, что и ядерные потоки не будут планироваться на эти ядра — это параметр
isolcpus. Тогда ваши задачи не сможет вытеснить никто, даже ядро. Правда, если у вас несколько таких изолированных процессов, то и балансировкой этих процессов между изолированными ядрами никто заниматься не будет.Актуально для open source проектов, где пул-реквест может представить любой, а не только члены закрытой команды разработчиков.
Не совсем понятно, а какой юз кейс вас напугал? То, что вы смогли отследить разработчиков между различными сервисами, используя Gravatar? Разве это проблема? Разработчики сами создали свой публичный профиль (бренд) и продвигают его: участвуют в разработке на github, отвечают на вопросы в stackoverflow и так далее. То есть это изначально публичная сущность, которая должна собирать в кучу виртуальную личность, которая пользуется кучей сервисов. То, что вы зная публичный email разработчика и нашли следы его активности где бы то ни было — это не бага, это фича.
Вот если бы выяснилось, что удалось связать между собой две виртуальные личности, одна из которых — разработчик, а вторая — кот, которые принадлежат одному человеку желающему разделить публичную и личную жизнь, вот тогда это была бы проблема приватности.
А утечка почты через MD5 — конечно неприятно, но это проблема уже Gravatar. Интересно, репортил ли автор проблему им и что они ответили.