• Список полезных идей для высоконагруженных сервисов
    0
    В целом разумно, но первый совет — очень спорный.

    ов. Если кто-либо говорит полную чушь, или говорит что-то, что противоречит вашей практике — не прислушивайтесь к таким советам, и не важно, насколько этот человек известный и уважаемый.

    Прислушиваться нужно. Проверять нужно. Часто бывает, что человек несёт полную чушь, потому что он думает уже не о «твоей маленькой проблеме», а больших последствиях твоего метода исправления маленькой проблемы.

    Часто бывает, что «чушь» — это иная парадигма и иной комплект ценностей. Например, вам могут нести чушь про идемпотентность и вред неявных сайд-эффектов. Чушь? Чушь. Слушать? Ну..., как сказать, можно и не слушать.
  • Отладка злого бага в рантайме Go
    +1
    Не торт. Они несут ахинею.
  • Двенадцать советов по повышению безопасности Linux
    0
    Увольте копирайтера, читать глаза болят. Особенно про «терминалы». Называть tty терминалом — это круто.
  • Отладка злого бага в рантайме Go
    +9
    Когда вы говорите «вы проделали», учитывайте, что это не mail.ru такие умные, а они всего лишь перевели с английского статью.
  • Не было печали, апдейтов накачали
    +3
    А каким образом у вас из анекдота «пол-года назад у меня сломалась система после апдейта» стало «гарантировано убивает графическую оболочку»?
  • Не было печали, апдейтов накачали
    +2
    Ubuntu имеет локальные бизнес-преимущества. Для энтерпрайза там есть платный саппорт, для остальных локальное (не очень хорошее, но всё-таки) актуальное состояние зависимостей (в частности, для openstack).

    А Debian — он просто есть. Это некоммерческий opensource проект с декларированной полиси и социальным контрактом. Так что дебиан — это база, «вечная ценность», а всякие его форки — всего лишь сиюминутная суета.

    Убунта постоянно пытается от дебиана уйти. upstart, mir, unity, snap (три из этих уже похоронили, следующий — snap), но не может, ибо ценность дебиана куда выше, чем любые локальные усилия одной компании.

    Дебиан работает над абстрактными ценностями, вроде reproducible builds, которые недоступны коммерческим компаниям (из-за масштаба проблемы и количества участников), лицензионной чистоты, свободы ПО и т.д.
  • Не было печали, апдейтов накачали
    +1
    Что за глупость?
  • Не было печали, апдейтов накачали
    +3
    Да. eatmydata. (apt-get install eatmydata, запускать eatmydata debootstrap, dpkg, etc).
  • Не было печали, апдейтов накачали
    +1
    Даже проверенное на стенде может показать регрессию на реальном продакшене. Она не обязательно на уровне «упало». Может ставить другие флаги на TCP, не поддерживать какой-то corner case в криптографии или делать performance regression под определённой нагрузкой.

    Очевидно, что есть workflow, позволяющий откатиться на предыдущую версию. Но чем ниже по стеку проблема (libc, openssl, kernel), тем менее гибкими являются эти технологии. В какой-то момент мы переходим к хостовой ОС, обновление и откат которой может быть двух видов: откат сервера и откат приложения/библиотеки.

    При всём хайпе насчёт унифицированных гомогенизированных серверов, которые можно откатывать по клику мышкой, очень часто проще откатить библиотеку на уровне хоста, чем возиться с миграцией 30Тб данных.
  • Не было печали, апдейтов накачали
    +5
    devops — это парадигма, с ней нельзя совещаться.
  • Не было печали, апдейтов накачали
    0
    В продакшене оно может пригодиться, а показывал я на примере домашней машине. В том же продакшене может прилететь супер oldstable апдейт с регрессией. И чинить его надо будет «сейчас», а не три дня спустя.
  • EU GDPR: соблюдение требований регуляторов в сфере облачных вычислений
    +1
    Увольте / подвергните порицанию человека, который это писал. Начал с обзора законов, а дальше у него случился эпилептический припадок с семантически нелепыми звуками вида «параллелз», «повышенная безопасность», «преимущества облаков», «легко защищать» и прочей ахинеей.
  • Пишем простой модуль ядра Linux
    0
    Я всё понимаю, но на современном x86_64 ring0 — это очень малопривилегированный режим. Есть ring -1 — гипервизор, есть SMM режим, и есть ring -2, использующийся MEI. Таким образом, если мы перенормируем циферки, то будет так:

    ring0 — MEI
    (где-то тут SMM)
    ring1 — hypervisor
    ring2 — kernel
    ring3 — userspace
  • Не было печали, апдейтов накачали
    +26
    Я как product owner, product manager, senior system administrator, CTO, CFO и CEO своего домашнего компьютера на совете директоров принял решение использовать debian Sid в продакшене на моём домашнем компьютере.
  • Не было печали, апдейтов накачали
    0
    Использование sid'а дома — куда более разумная вещь, чем может показаться. Свежие драйвера и версии софта — это приятно.
  • Не было печали, апдейтов накачали
    +1
    У меня на рабочем ноуте убунта у и меня umask тоже 0002 (т.е. создаётся с 0755). А что не так с этим? И почему вы пишите «в debian 9», если так было всю жизнь на всех дебианах?
  • Не было печали, апдейтов накачали
    0
    Предыдущие версии, это которые из стабильного дистрибутива, oldstabe, experimental и т.д.
  • Не было печали, апдейтов накачали
    0
    Вот, кстати, не знал. Пожалуй, один серьёзный аргумент в пользу dnf'а.
  • Не было печали, апдейтов накачали
    +3
    Нет. См выше про проблемы производительности и синхронизации бута с рутом. Снапшоты — вообще брутфорс и «я не могу починить, откатываемся».
  • Не было печали, апдейтов накачали
    +4
    Можно, конечно.

    Но:

    1) LVM снапшоты не бесплатны на запись. dpkg — один из самых агрессивных пользователей fsync'а, что транслируется в два fsync'а в нижележащий уровень. Банальным образом тормозим.
    2) Бага может выплывать много позже, чем был установлен пакет и откат может быть нежелательным.
    3) Откат rootfs без отката /boot может приводить к феерическим проблемам из-за отсутствия модулей для нового (откаченного) ядра, а EFI-снапшотов нам пока не завезли.

    sid хорош тем, что это почти rolling update. Всё более-менее свежее. FF Quantum, свежие драйвера, etc. Я никогда не сталкиваюсь с тем, что «оно там есть, но слишком новое для моей системы».
  • Эффект дизеринга в трёхмерной игре
    0
    Внезапно: www.youtube.com/watch?v=g6Ta35AiE1I 50% того, про что я говорил.
  • Эффект дизеринга в трёхмерной игре
    0
    Божественно. Это как раз то, про что я говорил. Дальше вопрос только файнтюнинга, а принцип — именно он.
  • Эффект дизеринга в трёхмерной игре
    0
    А, движение — это сложно.

    Олег хорошо объясняет. Это видео и остальные смежные:

    www.youtube.com/watch?v=BRW9rUTnSa8
  • Эффект дизеринга в трёхмерной игре
    0
    то есть вы хотите сказать, что если сделать что-то такое — это будет новое и неизведанное, а не изобретение велосипеда?
  • Эффект дизеринга в трёхмерной игре
    +4
    Я быстро набросал с вакомом (я им хуже владею, чем карандашом). Слева — штрих без формы, в центре — по форме, справа — рисунок по форме.


    (https://snag.gy/wMZpXL.jpg)

    Показать вопросы с движением и т.д. будет много сложнее, т.к. это уже потребует настоящего рисунка.
  • Текстуры кода
    +4
    Ни одного красивого примера в опенсорсе? Ужас какой.
  • Настройка звука в Ubuntu
    0
    Почему-то в списке того, что трогалось, ни слова про pactl /pacmd. У последнего есть даже интерактивный шелл с двумя экранами команд.
  • DLP-система DeviceLock 8.2 — дырявый штакетник на страже вашей безопасности
    0
    На фоне беспарольного рутового доступа на Эпплы — вполне себе надёжная система.
  • Текстуры кода
    +5
    Многое давно покрыто styleguide'ами. Оставшееся — слишком случайно, чтобы говорить про гармоничность. Более того, меня очень удивляет статья без фактических примеров.

    «Я увидел такой гармоничный код, что вам не покажу».
    «Потом я много раз обращал внимание, что хорошие программисты пишут красивый код, который я вам не покажу».

    Гипотеза: автор придумал идею в режиме «научно-фантастического допущения», а никаких реальных примеров не имеет.
  • Эффект дизеринга в трёхмерной игре
    +1
    По поводу гравюр уже написали выше, хочу добавить чуть-чуть, как интересующийся рисованием.

    Правила рисования:
    1. Штрих по форме. Внезапно, 3D модели знают свою форму, так что мы можем для любого ракурса реконструировать штрих по форме.
    2. Линия должна быть живой — её толщина должна показывать «энергичность» движения в данном месте. «Движение» в рисовании — направление изгиба основной оси объекта, игнорируя мелкие детали. В первом приближении — изгиб центра симметрии. Чем сильнее изгиб, тем больше движение. Энергичность движения — его значимость для зрителя (художника). Машинно определить это сложно, но довольно просто разметить на 3D-модели.
    3. Штрихи могут менять яркость (нажим), толщину, расстояние между ними, количество слоёв (в контексте гравюры — не больше двух).
    4. Если у художника mad skill, то он может использовать штрихи для передачи характерных элементов текстуры (волос, ткани, волокон дерева).
    5. При переломе формы лучше менять направление штриха. Перелом формы — это место, где резко уменьшается радиус кривизны. Вычисляется на 3д-модели в пол-пинка.

    Это всё вполне в рамках машины. Даже если пренебречь «энергичностью» движения, всё остальное вычисляется. Неужели никто не пробовал?
  • Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine
    +1
    Ну так практически все системы управления конфигурациями подразумевают такого рода декларативность. А на «полиси» для большого проекта такое примитивное правило — маловато.

    Кроме того, есть вещи, которые просто невозможно описать в декларативном виде. Даже ансибловое «state=restarted» — это не декларативное, это завувалированное императивное «перезапусти, пожалуйста».
  • Разработка для Sailfish OS: использование датчиков (часть 1)
    0
    С моей скромной колокольни, apt-get'овый синтаксис куда более человечен, чем rpm/yum'овый.
  • Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine
    0
    Неидемпотентные хендлеры — зло. (если скрипт сломался на service restart, то он должен повторить restart, после перезапуска плейбуки, даже если конфиги не менялись). Для этого в хендлерах рестарта должно быть просто выставление файлового флага (в районе /run), а потом обычная таска должна по этому флагу рестартиться. /run чистится при старте сервера, так что оно идеально для таких задач.

    Вот насчёт красненького, который хэндлерам не даёт отработать — это я не думал. Спасибо, буду думать. Плохо будет, если случится.
  • Разработка для Sailfish OS: использование датчиков (часть 1)
    –2
    Но система управления пакетами такая же часть UI, как и графическая подсистема. Во всяком случае в том смысле, как я воспринимал N9.
  • Разработка для Sailfish OS: использование датчиков (часть 1)
    0
    1. Увы, жаль. Maemo было куда круче. С позиции гика, разумеется, хотя и потребительские свойства были офигенны.
    2. Аналогично, жаль. Хочет свободного апстримового.
  • Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine
    0
    Опереться не на что. Если всё самому писать, то зачем ансибл? Редактор, и вперёд.

    Хорошая полиси позволяет получить хорошие практики и отрезать плохие на уровне синтакисиса или подразумеваемого workflow, а не на уровне дисциплины в команде.
  • Разработка для Sailfish OS: использование датчиков (часть 1)
    0
    Простите, что с наивными вопросами, но:

    1) Sailfish — это наследник maemo или meego? Пакеты dpkg ставятся или нет?
    2) X-сервер или что-то другое?
    3) Ядро апстримовое, своё или андроидовое?
  • Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine
    +1
    Кстати, идемпотентность есть и у шефа. Всей идемпотентности ансибла хватает на раскраску вывода в разные цвета и нотифиейшены, никакой другой пользы от них нет.
  • Как не положить тысячи серверов с помощью системы централизованного управления конфигурацией на примере CFEngine
    +1
    У шефа есть сущности, которые предназначены только для того, для чего их сделали. Пример — у нас есть кукбука, которая предоставляет рецепты и провайдеров. В ансибле этого нет — там есть роли, но роль — это всего лишь набор play's. И он не предоставляет, он выполняет. Ближайшим аналогом роли в ансибле будет… роль в шефе. Просто runlist.

    При этом ранлист в шефе состоит из рецептов кукбук, и каждая кукбука имеет свои переменные, свои тесты и позволяет использовать себя в разных местах несколько раз (например, собирая от других кукбук «заявки» на установку пакетов).

    В ансибле этого нет. Всё что там есть в ролях — это plays. На их базе можно попытаться реализовать подобие кукбук и рецептов, и более того, в крупных инсталляциях это приходится делать обязательно, через include_role с специально подготовленными переменными (специфичными для роли). Но это приходится изобретать самому, и поддерживать эту полиси силами дисциплины. А в шефе это — на уровне кода.

    Я как раз сейчас пишу большую простыню (на английском) про best practices для ансибла в сложных проектах. И большая часть того, что я пишу — это то, что «надо изобретать для себя самому», поскольку от ансибла нет никаких поддерживающих элементов.

    Например, в больших проектах надо обязательно различать execution groups (те, которые указываются в hosts в play'ях), query groups (те, которые опрашиваются в циклах внутри всяких acl'ек и т.д. на тему разрешения доступа), и group variables groups, задача которых — предоставлять общие переменные для всех членов этой группы.

    Вот если это разделение не соблюдать, будут постоянно вылазить косяки и неудобства. То мы лишнее пишем на хост (просто потому, что ему надо было дать доступ к базе данных), то мы лишний хост вписываем в acl'ы (потому что ему надо было что-то поправить), то кто-то имеет перекрытие переменных из разных групп, то кто-то не видит нужные переменные.

    Вот эту штуку — тоже надо поддерживать полисей в голове, и никак не иначе.
  • Диагностика промышленных электродвигателей и генераторов по спектру потребляемого тока и предотвращение аварий
    0
    Не «к облаку». Всё что требуется — это машиночитаемый вывод и поддержка инструментария для автоматизации.

    Автоматизация — это куда более serious чем хайп с облаками и контейнерами. Облака приходят и уходят, а автоматизация остаётся (вместо человека) работать.