• Intel vs AMD: сравнительные тесты
    0

    Такие кейсы мы рассмотрим и постараемся обо всём этом написать, но уже в новом году.

  • Intel Optane SSD: возможности и преимущества
    0
    Опечатка. Исправлено. Спасибо!
  • Выделенные серверы на базе процессоров Intel Xeon Skylake-SP
    0
    Что вы этим хотите сказать?
    Если у вас есть замечания по существу, высказывайтесь развёрнуто здесь или в личном сообщении мне.
    Если вы преследуете какие-то другие цели, то нам с вами не по пути.
  • Выделенные серверы на базе процессоров Intel Xeon Skylake-SP
    0
    13,75 МБ на ядро — опечатка; спасибо, что заметили, я исправил.
  • Ubuntu 17.04: что нового
    +1
    Исправлено, спасибо!
  • Ubuntu 17.04: что нового
    0
    Я знаю, что письма Марка ещё не было. Но информация именно о таком варианте имени уже гуляет по Интернету…
  • Почему в сорок лет я решил поменять профессию и стать программистом Python
    0
    Вы отлично всё написали. У меня всё было ещё грустнее, чем у Вас: 90-е, отдалённый регион, не самое лучшее филологическое образования, аспирантура (не та, куда хотел), преподавание (не то, о котором изначально мечтал). В 30 ушёл из вуза в никуда. Работал переводчиком, потом стал работать техническим писателем. Изучаю C и Python. Скоро меняю работу на более интересную.
  • Управление контейнерами с runC
    0
    Мы постоянно пишем о контейнеризации, стараясь затрагивать интересные аспекты темы. Вот другие статьи из цикла:

    https://habrahabr.ru/company/selectel/blog/308208/
    https://habrahabr.ru/company/selectel/blog/303190/
    https://habrahabr.ru/company/selectel/blog/271957/
  • Введение в DPDK: архитектура и принцип работы
    +1
    Вообще от поллинга отказались, ибо проц в холостую пашет, но зато задержки типа меньше.


    Если честно, не понял, что вы имеете в виду. Попробуйте, пожалуйста, сформулировать эту мысль другими словами.

    DPDK вроде как прибит на гвозди к интелу.


    Да, DPDK был создан Intel для собственных сетевых карт. Драйверы для других карт (<a href=«http://dpdk.org/doc/guides/nics/mlx4.html» target="_blank" rel=«nofollow»">Mellanox, Emulex) есть, но с ними далеко не все гладко. Например, во время экспериментов с DPDK мы установили драйвер для Mellanox, но ничего не завелось, хотя всё делали точь-в-точь по инструкции. Зато все получилось сразу, как только мы заменили карту Mellanox на Intel.

    netmap работает с кучей железа, там есть какие то минимальные требования к самим сетевухам, типа наличия DMA и колец дескрипторов.
    Автор — Луиджи впилил поддержку в дрова реалтека, интела и пр.


    Да, netmap гораздо менее «завендорлочен». Ну и тут есть свои подводные камни: например, полноценной поддержки карт Mellanox нет до сих пор (см. здесь).
  • Введение в DPDK: архитектура и принцип работы
    +1
    К сожалению, в течение последних двух дней был вдалеке от компьютера и Интернета, поэтому отвечаю только сейчас.

    … вы уж сильно не обижайтесь =)

    Обижаться и никто и не собирается =) Более того, моя реакция будет совершенно противоположной: я очень рад, что вы внимательно прочитали статью и благодарен вам за конструктивные замечания. Вообще, обижаться на критику, если она конструктивная — это не про меня. Я не боюсь признавать свои ошибки, а тот же Хабр считаю местом не для демонстрации собственной крутизны, а для дискуссий, взаимного обучения и обмена мнениями.

    по этому слинковать приложение, используюещее сокет апи с дпдк просто так в лоб не получится (на самом деле на сегодняшний день существует ряд TCP стеков поверх дпдк — rumptcp, mtcp(кстати от автора packetshader))


    Прекрасно понимаю и сейчас жалею, что ясно не выразил это в тексте.Спасибо за замечание. Про TCP-стеки поверх DPDK обязательно почитаю поподробнее (кстати, если знаете полезные ссылки по теме, буду очень признателен).

    На самом деле кольцевая структура — rx ring — это кольцо дескрипторов. В этой структуре не содержатся сами пакеты (они сперва попадают в fifo буфер NIC), там содержатся указатели на область памяти, куда делать DMA + ряд других полей, куда NIC пишет после успешного DMA (write back), например длина пакета, оффлоадинг флаги итд.


    Это я знаю; в тексте выразился не совсем удачно. Все указанные вами сомнительные и неудачные фразы я либо отредактировал, либо вообще убрал.

    … то, что вы называете головой и хвостом в rte_ring.h называется prod.head и cons.head


    Это я знаю. Там ещё prod.tail и cons.tail есть. И здесь мы уже из обсуждения чисто технических деталей смещаемся в плоскость терминологии и стилистики. Конечно, в тексте можно писать как в rte_ring.h — но это делает его более тяжеловесным и нечитабельным. Я не пурист, не против заимствования терминов из других языков (если в нашем языке таковых нет), но ералаша из русских и латинских букв в тексте не люблю. К тому же термины «голова» и «хвост» применительно к кольцевому буферу в русском языке можно считать общеупотребительными.

    Ничего не понятно что вы имели ввиду. С одной стороны — да, rte_mbuf сильно меньше sk_buff, но его нельзя сравнивать с так же разросшимся mbuf во FreeBSD.


    Насколько я понимаю, истоки идеи, лежащей в основе rte_mbuf, восходят к FreeBSD. Если в Linux для всех типов пакетов используется структура sk_buff (о недостатках такого подхода мы уже говорили выше), то в FreeBSD используются mbuf, которая гораздо меньше по размеру и которые для обработки больших пакетов могут объединяться друг с другом (как buffer chaining в DPDK). Когда я прочитал про rte_mbuf, мне это сразу напомнило «фряху».

    Вот для примера Брюс Ричардсон несколько часов назад читал доклад, в котором показал один из кейсов поиска узкого места.


    За ссылку на доклад огромное спасибо!

    В заключение хочу ещё раз поблагодарить вас за все высказанные замечания, эта как раз так критика, которая помогает нам стать лучше =). Именно ваш комментарий оказался самым ценным из всех.
    При работе над следующей статьёй многие ваши замечания я буду держать в уме.

    И хотел бы спросить: а где вы так хорошо изучили DPDK? используете ли вы DPDK для решения каких-то практических задач? Заранее благодарю и надеюсь на продолжение диалога.

  • Введение в DPDK: архитектура и принцип работы
    0
    Спасибо за уточнение по поводу DMA!
  • Мониторинг безопасности с Sysdig Falco
    +1
    Я эту картинку прекрасно знаю. Более того, мы в одной из предыдущих публикаций её уже использовали.
    Если говорит о Sysdig, то он собирает информацию абсолютно обо всём и с его помощью можно сделать то, для чего в других условиях потребовалось бы несколько инструментов. Он сразу показывает то, что с помощью других инструментов нужно ещё «нарыть».
    А ещё он отличается гибкостью и низким порогом вхождения (синтаксис тех же правил и фильтров очень прост).

    Что касается Falco, то он умеет гораздо больше, чем другие инструменты для аудита безопасности, а ещё даёт гораздо более подробную и человекопонятную информацию.
  • PipelineDB: работа с потоками данных
    0
    Про RethinkDB слышал, но не более того. Спасибо за информацию, надо бы изучить поподробнее.
  • Облачное хранилище: новые функции API
    0
    Подробности здесь: https://habrahabr.ru/company/selectel/blog/304032/
  • Облачное хранилище: новые функции API
    0
    >>>>А у OpenStack Swift API примерно 10 июня этого года вы изменили имя контейнера с Common на common (да-да, они регистрозависимые), остановив работу трех моих приложений.>>>>

    Из такой формулировки неясно, что имеется в виду. Поясните, пожалуйста. И если такая проблема была, лучше пишите о ней не здесь, а создайте тикет с как можно более подробным описанием.
  • Rclone: rsync для облаков
    0
    C Яндекс-диском не пытался, только с Google Drive.
  • Gogs: легковесный git-сервис
    0
    Запросы соответствующие есть:

    https://github.com/gogits/gogs/issues/936
    https://github.com/gogits/gogs/issues/776

    Будем надеяться, что реализуют, и ждать долго не придётся.
  • RAML 1.0: обзор нововведений
    +1
    Любой инструмент должен использоваться сугубо по назначению. JSON был создан для обмена данными в вебе, а не для описания API — об этом здесь в комментариях уже писали. Поэтому при составлении документации к API поневоле приходится прибегать к помощи «костылей». Да и составлять в JSON длинные описания довольно утомительно… И не менее утомительно их читать (на это уже обратил внимание другой комментатор).
  • Трассировка ядра с ftrace
    0
    Нет. Конечно же, "переключения". Спасибо, поправил.
  • Евклидов алгоритм генерации традиционных музыкальных ритмов
    0
    Насчёт Мессиана Вы правы, очень не хватает. И в свете прочитанной статьи было бы интересно взглянуть на его трактат о ритме другими глазами.
    А ещё интереснее было бы развить тему на обширном материале авангардной музыки ХХ века, которая во многом инспирирована опытом неевропейских культур и традиций.
  • HTTP/2: готовимся к переходу
    0
    Да, это момент я уже поправил.
  • HTTP/2: готовимся к переходу
    0
    Это какие браузеры? Я просто давно мечтаю о таком, но не видел нигде еще.
    Поправил: это ещё не реализовано. Но скоро будет внедрено и в Chrome, и в Firefox:

    https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
    https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
  • HTTP/2: готовимся к переходу
    +1
    Во-первых, это не совсем перевод. Во-вторых, мы и не скрываем, что использовали эту статью.
  • Мониторинг сервисов с Prometheus
    0
    Если не секрет, чем вас не устроил Prometheus? Почему в качестве стороннего сервиса выбрали именно DataDog?
  • Мониторинг сервисов с Prometheus
    +1
    Почитайте здесь: stackoverflow.com/questions/33350314/usecases-influxdb-vs-prometheus.

    Весьма любопытная дискуссия, в которой участвуют ведущие разработчики Prometheus и InfluxDB. Возможно, найдёте какие-то интересные мысли по теме.
  • Пишем документацию API при помощи RAML
    0
    Да, сами описания выглядят несколько громоздко, что немного напрягает.

    >>>Автоматические генераторы есть, и тут уже больше философский вопрос, что первично — документация или код. Мне близок подход, когда сперва составляется осмысленная документация.>>>>

    Я ничего не имею против этого подхода. Задавая свой вопрос, я никаких философских аспектов затрагивать не хотел. Мне действительно интересно, насколько сейчас распространён WSDL, как он поддерживается сообществом, какие есть вспомогательные инструменты.
  • Пишем документацию API при помощи RAML
    0
    Слишком сложно…

    Кстати, а существуют ли какие-нибудь генераторы интерактивной документации для WSDL?
  • Пишем документацию API при помощи RAML
    0
    Присоединяюсь к вопросу.
  • Пишем документацию API при помощи RAML
    0
    >>>>Учитывая что эти форматы чаще употребляются сриптами чем читаются человеком (зачем это читать если можно посмотреть что в UI нагенерили для каждого endpoint) то логичность синтаксиса — это вопрос второй. >>>>

    Даже для скриптов лучше писать в простом формате и без лишних «костылей».

    >>>>Для RAML есть генераторы клиентов, как например AutoRest для .NET?>>>>
    Есть, но пока что они находятся в очень «сыром» состоянии.

    >>>>А вот коммунити — это наживается непросто. За RAML стоит одна компания, как и за API Blueprint. Swagger старается вовлечь сообщество в стандарт.>>>>>

    За RAML стоит не одна компания. В разработке спецификаций принимали участие представители Cisco, PayPal, BoxInc. Насчёт коммьюнити — оно уже формируется (см., например, здесь: raml.org/projects.html)
  • Пишем документацию API при помощи RAML
    +1
    Разные задачи — разные инструменты.
  • Пишем документацию API при помощи RAML
    +2
    Насколько мне известно, пока что нет.
  • Пишем документацию API при помощи RAML
    +2
    Чем лучше? Отвечаю по пунктам?

    1. Гораздо более простым и логичным синтаксисом описаний.
    2. Возможностью расписать в документации гораздо большее количество параметров, чем в том же swagger и, самое главное, сделать это при помощи более простых и удобных конструкций (сравните те же описания схем безопасности или query-параметров).
    3. Расширенными (по сравнению с тем же swagger) возможностями использования include'ов и наследования, благодаря чему документация получается более компактной и элегантной.

    Единственное, в чём RAML пока что проигрывает Swagger — недостаточное количество разрабатываемых сообществом инструментов. Но это — дело наживное.
  • Пишем документацию API при помощи RAML
    +1
    >>>>валидация данных по RAML-схемам есть?>>>>

    Есть. Вот ссылка на инструмент для валидации: www.npmjs.com/package/raml-validate

  • Управление логгированием в systemd
    0
    Спасибо за интересное дополнение!
  • Нужна ли в России поддержка национальных разработчиков ПО? Once upon a time in Russia
    0
    >>>К тому же, не сравнивайте миллиард китайцев с 150 лямами россиян, из которых лишь часть пользуется инетом<<<<

    Китай — он тоже разный. Там есть не только богатые Пекин и Шанхай, но и куча забытых Богом и цивилизацией мест — например, неблагополучный как с политической, так и экономической точки зрения Синцзян-Уйгурский автономный район. Поинтересуйтесь, как в Китае живут на селе — там, мягко говоря, далеко не все гладко. С Интернетом в сельской местности в России (при всех имеющихся трудностях) получше будет.
  • Нужна ли в России поддержка национальных разработчиков ПО? Once upon a time in Russia
    +3
    Полное импортозамещение в случае с ПО вряд ли представляется возможным. Выше уже было сказано, почему.
    Десятипроцентные налоги и прочие проекты подобного рода я считаю не просто глупостью, а прямым вредительством. В нашей стране давно уже назрела необходимость модернизации, которая невозможна без поддержки высокотехнологичных отраслей экономики. Высокотехнологичный сектор (см. опыт Китая, Сингапура, Бразилии), должен быть вообще не облагаемым налогами либо облагаемым по минимуму.
    Поддержка отечественного производителя на госзакупках, думаю нужна. Здесь опять же можно воспользоваться китайским опытом.
  • Нужна ли в России поддержка национальных разработчиков ПО? Once upon a time in Russia
    +2
    Насчет менталитета — все верно. Но причины китайской нелюбви к западному ПО имеют не политико-идеологический, а культурный характер. Наши европейские представления о дизайне (о пространственном расположение элементов, цветах и т.п.) очень плохо вписываются в контекст китайской культуры. Это одна из причин, по которым они делают все свое. И получаются у них не хуже, а иногда даже лучше.
  • Нужна ли в России поддержка национальных разработчиков ПО? Once upon a time in Russia
    +2
    Добавлю, что китайцы еще в конце 1990-х — начале 2000-х старались не использовать продукты Microsoft. Уже тогда у них был свой пакет King Soft Office, специально адаптированный под работу с китайской письменностью.
  • Статические сайты: настройка и оптимизация
    +2
    Вы вообще за Уралом были когда-нибудь? На российском Дальнем Востоке были? Представляете себе, какие там расстояния? Если контент пойдет на Камчатку не через Новосибирск, а через Монголию, то это вообще будет не заметно — расстояние примерно одно и то же. Более того, для Дальнего Востока точки присутствия в том же Китае будут горазо выгоднее по целому ряду причин.
  • Статические сайты: настройка и оптимизация
    +1
    Прочитал Ваш комментарий, и у меня тут же возник вопрос: а есть ли вообще какие-нибудь CDN, у которых в России есть точки присутствия восточнее Новосибирска? В дальневосточном регионе, напримре, есть у кого-нибудь точки присутствия?