Я очень уважаю компанию ZeroTurnaround вообще и их статьи в частности. Они реально молодцы. А вот перевод настолько старых статей — нет. Это вводит публику в сильное заблуждение. Сейчас технологии ускакали очень далеко вперёд. И есть сильное подозрение, что текущее соотношение сил тоже отличается очень сильно.
По идее надо просто сделать систему как на StackOverflow: если плюсуешь — то просто плюсуешь. Если минусуешь, то минус прилетает и тебе тоже. Т.о. человек стри раза подумает, прежде чем на минус нажать.
Поддерживаю вопрос и хочу уточнить. Не в какой-нибудь форк, а в основную ветку OpenSSL. Ну и стандартные, не форкнутые, браузеры тоже интересуют. И под Linux тоже.
В целом про eagel или scrum можно сказать точно так же. Разница лишь в том, что они старше и люди уже чётко договорились что конкретно под этим следует понимать. А с DevOps общественность ещё в поиске. Просто начало формироваться видение, что те-же производственные задачи можно решать ещё одним способом, который меньше полагается на договорённости и человеческий фактор, а больше на автоматизацию и алгоритмически прописанные правила.
Но пока опыт у всех разный. Общий знаменатель ещё не подведён. Потому и получается такой аморфный шум. Для меня тоже ещё много белых пятен в этом. Потому и стараюсь попасть на конференции по этому вопросу, чтобы иметь возможность пообщаться с людьми имеющими свой, альтернативный опыт.
Ну вот я уже несколько лет вокруг этого кручусь. Что получил в итоге? Инструменты есть, а DevOps'а нет! Почему? Потому, что инструменты должны быть не как цель, а как следствие стремления людей что-то улучшить. Улучшить глобально. Найти общий язык всех со всеми. Понять что таки нужно на самом деле и сделать это.
Инструменты — всего лишь инструменты. Без правильно настроенных на нужный результат людей это так и останется мёртвым грузом.
И камень с мёртвой точки у меня начал смещаться именно когда я понял, что DevOps это про людей и именно про людей. Если правильно нашёл заинтересованных, корректно подал им мысль что и как можно улучшить, порекомендовал полезные решения, помог их реализовать, и т.д. и т.п… Внезапно всё раз — и побежало. И начали появляться решения, эти решения начали использоваться пошол DevOps.
А то, что вы описали — скорее таки SysOps. Да Он тоже нужен. Но это в целом очень другая относительно разработки компетенция. И грамотный сисадмин с классическими подходами тут может оказаться гораздо ценнее.
Сисадмин не должен программировать сложные системы. Программист не должен тюнить СХД. Один человек не в состоянии иметь глубокую компетенцию везде. Иначе будет беда.
А вот взаимодействие этих гатегорий людей ради конкретного результата — вот это уже ближе к DevOps. Но таки людей.
SysOps — это про настройку оборудования, чтобы оно работало правильно и быстро. А DevOps — это про настройку разработчиков, чтобы они работало правильно и быстро.
Полностью подписываюсь под словами Баруха и Александра. Самое сложное — переломить сознание людей. Заставить их сотрудничать и не тянуть одеяло на себя. А инструменты — дело наживное.
К слову опцию CMAKE_TOOLCHAIN_FILE можно задать и в корневом CMakeLists.txt перед директивой project. Чтобы не требовать указывать это вручную в настройках IDE.
Получается две конфигурации. Для debug и для release. В версии release активирована максимальная оптимизация по размеру, плюс full link time optimization (flto). Это такая хитрая функция современного GCC, когда в объектные файлы пишется не только готовый машинный код, но и специальный байткод синтаксического разбора (на сколько я понял). Задаётся это флагами -flto -ffat-lto-objects. В проектах на большом брате можно обойтись и без -ffat-lto-objects. Но на STM32 не получается.
Далее в дело вступает линкер, который при заданной опции -Wl,-flto вычитывает из объектных файлов уже не машинный код, а подготовленный на предыдущем шаге байткод. И проводит агрессивную оптимизацию уже в рамках всего исполняемого файла (прошивки). Что приводит к тому, что прошивка существенно сокращается в объёме и при этом становится намного производительнее.
На "помигать светодиодом" получается около 3.5 Кб вместо 18 Кб.
Ну пока вы в "зелёной зоне Шипилёва" ( презентация, 8-я страница ), то профайлеры работают отлично. Но вот уже в жёлтой зоне начинают нещадно сбоить и показывать ерунду. Про красную я вообще молчу...
Т.е., по сути склонировать меркуриаловский репозиторий без развёртывания локальной копии файлов, перейти в каталог и встать на конкретную ревизию (собственно развернуть файлы этой ревизии). Так вот: первые две команды всегда проходят нормально, а вот последняя с некоторым небольшим шансом падает. То говорит, что подкаталой какой-либо не найден, то прав нехватает, то ещё что… При том, что половину репозитория успешно разворачивает, а потом падает.
Огромное спасибо за ответ. Статью читал сразу после публикации, так что некоторые детали успел запамятовать, а сейчас читал по диагонали и просмотрел про xattr. Каюсь. Остальное тоже попробую. Ну и по поводу relatime — нет, не уверен :-). Тоже можно поиграться.
Я очень уважаю компанию ZeroTurnaround вообще и их статьи в частности. Они реально молодцы. А вот перевод настолько старых статей — нет. Это вводит публику в сильное заблуждение. Сейчас технологии ускакали очень далеко вперёд. И есть сильное подозрение, что текущее соотношение сил тоже отличается очень сильно.
По идее надо просто сделать систему как на StackOverflow: если плюсуешь — то просто плюсуешь. Если минусуешь, то минус прилетает и тебе тоже. Т.о. человек стри раза подумает, прежде чем на минус нажать.
Поддерживаю вопрос и хочу уточнить. Не в какой-нибудь форк, а в основную ветку OpenSSL. Ну и стандартные, не форкнутые, браузеры тоже интересуют. И под Linux тоже.
Как и при диктовке. Чтобы можно было получать что-то вроде стенограммы разговора. С разделением реплик по участникам.
Интересно было бы, чтобы она ещё и собеседников могла различать. И отслеживать контекст каждого в отдельности.
В целом про eagel или scrum можно сказать точно так же. Разница лишь в том, что они старше и люди уже чётко договорились что конкретно под этим следует понимать. А с DevOps общественность ещё в поиске. Просто начало формироваться видение, что те-же производственные задачи можно решать ещё одним способом, который меньше полагается на договорённости и человеческий фактор, а больше на автоматизацию и алгоритмически прописанные правила.
Но пока опыт у всех разный. Общий знаменатель ещё не подведён. Потому и получается такой аморфный шум. Для меня тоже ещё много белых пятен в этом. Потому и стараюсь попасть на конференции по этому вопросу, чтобы иметь возможность пообщаться с людьми имеющими свой, альтернативный опыт.
Ну вот я уже несколько лет вокруг этого кручусь. Что получил в итоге? Инструменты есть, а DevOps'а нет! Почему? Потому, что инструменты должны быть не как цель, а как следствие стремления людей что-то улучшить. Улучшить глобально. Найти общий язык всех со всеми. Понять что таки нужно на самом деле и сделать это.
Инструменты — всего лишь инструменты. Без правильно настроенных на нужный результат людей это так и останется мёртвым грузом.
И камень с мёртвой точки у меня начал смещаться именно когда я понял, что DevOps это про людей и именно про людей. Если правильно нашёл заинтересованных, корректно подал им мысль что и как можно улучшить, порекомендовал полезные решения, помог их реализовать, и т.д. и т.п… Внезапно всё раз — и побежало. И начали появляться решения, эти решения начали использоваться пошол DevOps.
А то, что вы описали — скорее таки SysOps. Да Он тоже нужен. Но это в целом очень другая относительно разработки компетенция. И грамотный сисадмин с классическими подходами тут может оказаться гораздо ценнее.
Сисадмин не должен программировать сложные системы. Программист не должен тюнить СХД. Один человек не в состоянии иметь глубокую компетенцию везде. Иначе будет беда.
А вот взаимодействие этих гатегорий людей ради конкретного результата — вот это уже ближе к DevOps. Но таки людей.
Недавно сформулировал для себя такое определение:
SysOps — это про настройку оборудования, чтобы оно работало правильно и быстро. А DevOps — это про настройку разработчиков, чтобы они работало правильно и быстро.
Полностью подписываюсь под словами Баруха и Александра. Самое сложное — переломить сознание людей. Заставить их сотрудничать и не тянуть одеяло на себя. А инструменты — дело наживное.
А что, уже есть китай умеющий предавать по воздуху FULLHD на растояние в несколько километров? И при этом с меньшей задержкой?
К слову опцию
CMAKE_TOOLCHAIN_FILEможно задать и в корневомCMakeLists.txtперед директивойproject. Чтобы не требовать указывать это вручную в настройках IDE.Как-то поздновато на статью набрёл. Сейчас занимаюсь точно такими же экспериментами. Так что "лирику" читал — как про меня написано :)
Могу поделиться ещё и своими находками в плане флагов:
Получается две конфигурации. Для debug и для release. В версии release активирована максимальная оптимизация по размеру, плюс full link time optimization (flto). Это такая хитрая функция современного GCC, когда в объектные файлы пишется не только готовый машинный код, но и специальный байткод синтаксического разбора (на сколько я понял). Задаётся это флагами
-flto -ffat-lto-objects. В проектах на большом брате можно обойтись и без-ffat-lto-objects. Но на STM32 не получается.Далее в дело вступает линкер, который при заданной опции
-Wl,-fltoвычитывает из объектных файлов уже не машинный код, а подготовленный на предыдущем шаге байткод. И проводит агрессивную оптимизацию уже в рамках всего исполняемого файла (прошивки). Что приводит к тому, что прошивка существенно сокращается в объёме и при этом становится намного производительнее.На "помигать светодиодом" получается около 3.5 Кб вместо 18 Кб.
CLion вполне умеет в удалённый дебаг через gdb->OpenOCD->TS-Link. Отлично работает. Шью тоже через OpenOCD.
Всяких контроллероспецифичных мониторингов иногда не хватает, но они лично мне не очень-то и нужны.
А т.к. я 80% времени сижу в IDEA то перескакивать между разными IDE неохота. Начинаю сбиваться.
> Supports 12V DC power input
> Supports 12V DC power input
Ну пока вы в "зелёной зоне Шипилёва" ( презентация, 8-я страница ), то профайлеры работают отлично. Но вот уже в жёлтой зоне начинают нещадно сбоить и показывать ерунду. Про красную я вообще молчу...
Не удержался и зарепортил хотелку: https://www.yourkit.com/forum/viewtopic.php?f=3&t=39286
Надеюсь Андрей не будет против.
ну если надо, чтобы прямо здесь и сейчас, то:
И своп полностью ушёл в память. Главное, чтобы этой самой памяти хватило.
Спасибо за советы. Немного подрихтовал стало значительно лучше. По сути пересоздал том:
И перезалил туда данные.
По дороге наткнулся ещё на одну граблю: на CentOS сильно мешает работе SELinux. Пытаюсь выполнить следующий скрипт:
Т.е., по сути склонировать меркуриаловский репозиторий без развёртывания локальной копии файлов, перейти в каталог и встать на конкретную ревизию (собственно развернуть файлы этой ревизии). Так вот: первые две команды всегда проходят нормально, а вот последняя с некоторым небольшим шансом падает. То говорит, что подкаталой какой-либо не найден, то прав нехватает, то ещё что… При том, что половину репозитория успешно разворачивает, а потом падает.
Отключение SELinux решило проблему.
Огромное спасибо за ответ. Статью читал сразу после публикации, так что некоторые детали успел запамятовать, а сейчас читал по диагонали и просмотрел про xattr. Каюсь. Остальное тоже попробую. Ну и по поводу relatime — нет, не уверен :-). Тоже можно поиграться.