Если вы имеете в виду, что минимальная сборка занимает 50-100MB оперативной памяти, то это совсем не минимальная сборка, а как раз вполне обычный дистрибутив, в котором из авто запуска выкинули не нужные демоны.
Код становится запутанным из-за таких программистов, а не из-за C++ или стандартов.
Некоторые просто использую все возможные новые фичи языка, где нужно и где не нужно.
mingw на пример, как собирал бинарники, которые работают на xp, так и собирает.
работают ли новые версии самого mingw под xp не знаю, т.к. использую кросс компиляцию. Но старые версии mingw работали на xp.
Да я предпочитаю делать все в локально или брать за основу master из gitlab репозитория.
Пушить в master может не очень много людей, и все только в gitlab репозиторий.
Github pull requests не могут нормально объединяться (merge) в любом случае. они портят визуально историю.
Т.е. сначала я делаю git pull --rebase для gitlab репозитория, потом скрипт делает push во все репозитории. Если надо, можно вручную можно смержить pull request из github.
В данном случае я делаю push во все копии скриптом, т.к. их больше 2.
Но для просто копирования, в gitlab есть система копирования. Она кажется раз в сутки подтягивает данные.
Пулл реквесты предпочитаю принимать в gitlab, но можно и там и там. Т.к. синхронизация идет с локального компьютера.
Пример скрипта? Добавлены remot'ы на все репозитории.
Далее при запуске скрипта ему передается название бранча или на пример --tags.
И скрипт выполняет последовательно команды для всех репозиториев-клонов: git push REMOTENAME $1
Т.о. образом можно одной командой пушить одну ветку или теги. ./script master или ./script --tags
Можно было не использовать скрипт, но прописать все клоны в origin репозитория одновренно, но тогда могут быть некоторые проблемы. Если какая-то из копий выйдет из строя, то push может остановиться на пол пути. Также проблема будет с pull из этих веток.
Gitlab CI беспланет на любом gitlab хостинге или собстенном сервере с gitlab. Деньги начинаются если вы сами хостите Gitlab большей ревизии чем CE.
Все эти CI сервисы, включая Travis Ci поддерживают docker. Т.е. если вам надо, вы можете запускать любой контейнер, который найдете на docker hub, или дополнительно с gitlab хостинга, если вы используете gitlab ci.
И выполнять в нем все что вам угодно.
Я использую все эти CI за исключением appveyor. Репозиторий миррорится с gitlab.com на github.com
CI с gitlab.com самый быстрый, но не стабильный. Часто он тормозит или вообще не работает.
На остальных сервисах иногда возникают tmeout'ы.
MacOS поддерживается только Travis и если использовать свой раннер Gitlab CI (т.е. надо свой хост с macos). Платные варианты не рассматриваю.
На linux системах самба не устанавливается по умолчанию.
Самба нужна только для поддержки обмена файлами между windows машинами. Т.е. самба может стоять на линукс системе, которая выполняет роль файл помойки для windows. В любых других случаях она бесполезна.
Так что критичность этой проблемы сильно преувеличена.
Travis Ci это самый медленный сервис среди Gitlab Ci, Semaphore Ci, Circle Ci.
Если у вас всего несколько билдов, то это не большая проблема. А если их много, лучше смотреть на что-то другое чем Travis Ci.
Для gcc вы можете не использовать -msse4 и другие sse ключи компилятора, а использовать атрибут target у функции. Также можете отдать выбор по какой ветке идти с sse, avx или без для компилятора или libc, либо оставить выбор пути как у вас сейчас.
Используя препроцессор и проверку на gcc в нем, вы можете сделать что sse/avx будут работать автоматически в gcc, а для других компиляторов, надо указывать ключики.
a[16] для valgrind скорее всего будет корректен, если не вставится паддинг после a. А ubsan или asan выведет ошибку.
Или тоже самое, только уже разные структуры или массивы, но по указателю из первой структуры через переполнение индекса вы попадете, во вторую. Тут тоже asan/ubsan должен сработать.
Пропустить может если там будут указатели а не массивы.
Как я понимаю jmalloc это нестандартный аллокатор и отладчик для хипа. А valgrind это проверка всего и сразу. Хотя часть можно отключить. Он проверяет переполнения, обращения по некорректным адресам, утечки и д.р.
Еще есть более быстрый вариант. Это asan/ubsan. Он может проверять уже кое что, чего valgrind не может, но в тоже время чуть менее надежно.
Для использования *san надо собирать приложение с нужными флагами. Работа замедляется в несколько раз, но получается почти c/c++ с проверкой корректности работы с памятью.
Вы не написали основную проблему systemd — нестабильность.
Если по какой-то причине любая часть systemd заглючит, с большой вероятностью init процесс будет работать некорректно или упадет. если упадет init, то упадут все процессы.
Т.к. systemd лепит почти все функции в init процесс. Тоже самое с безопасностью, т.к. все части обращаются к init процессу, его могут поломать.
Еще люди пишут что при загрузке какой-то юнит может повиснуть, и значит все система уже не загрузится. Либо если какой-то юнит упадет при загрузке, будет непонятно что. Но это думаю уже зависит от криво настроенных зависимостей.
В классических init системах, init процесс запускает что-то и более ничего не делает.
Или еще одна проблема из-за systemd, теперь много софта собирается с поддержкой systemd, и не может без него работать.
На пример если взять debian, чтобы записать cd через графическое приложение, systemd обязателен. Но какое отношение systemd имеет к записи cd? Права? так можно было сослаться что нет прав на устройство.
Еще одна проблема systemd монолитность. Он включает в себе и заменяет почти все что можно. есть веб сервер, сканер штрих кодов, dns сервер и т.д. эти части сильно завязаны друг на друга, и у вас нет возможности заменить какую-то из частей systemd на альтернативы.
Другая проблема, не знаю может её уже исправили. Если при загрузке включить лог ядра, то systemd зависает или падает.
это не инструкция как исправить уже случившуюся проблему, а инструкция для предварительных действий.
В такой конфигурации я удалил libc, но все нормально восстановилось. скопировал через sshfs и mc распакованный пакет.
Можно попробовать запустить на сервере, на котором происходят работы:
1. sshfs смонтировать директорию с другого сервера.
2. открыть ssh соединение на тот сервер, откуда смонтирована директория.
3. запустить mc.
Если на текущем сервере что-то повреждается, то по ssh можно сразу сделать исправление на удаленном сервере. потом при помощи mc и sshfs скопировать на сервер с повреждением.
Можно заменить mc на busybox или еще что-то. но с mc сложнее еще раз ошибиться.
Вы просто выбираете нужную дату и получаете ссылку на репозиторий на эту дату
Некоторые просто использую все возможные новые фичи языка, где нужно и где не нужно.
работают ли новые версии самого mingw под xp не знаю, т.к. использую кросс компиляцию. Но старые версии mingw работали на xp.
Пушить в master может не очень много людей, и все только в gitlab репозиторий.
Github pull requests не могут нормально объединяться (merge) в любом случае. они портят визуально историю.
Т.е. сначала я делаю git pull --rebase для gitlab репозитория, потом скрипт делает push во все репозитории. Если надо, можно вручную можно смержить pull request из github.
Но для просто копирования, в gitlab есть система копирования. Она кажется раз в сутки подтягивает данные.
Пулл реквесты предпочитаю принимать в gitlab, но можно и там и там. Т.к. синхронизация идет с локального компьютера.
Пример скрипта? Добавлены remot'ы на все репозитории.
Далее при запуске скрипта ему передается название бранча или на пример --tags.
И скрипт выполняет последовательно команды для всех репозиториев-клонов: git push REMOTENAME $1
Т.о. образом можно одной командой пушить одну ветку или теги. ./script master или ./script --tags
Можно было не использовать скрипт, но прописать все клоны в origin репозитория одновренно, но тогда могут быть некоторые проблемы. Если какая-то из копий выйдет из строя, то push может остановиться на пол пути. Также проблема будет с pull из этих веток.
Все эти CI сервисы, включая Travis Ci поддерживают docker. Т.е. если вам надо, вы можете запускать любой контейнер, который найдете на docker hub, или дополнительно с gitlab хостинга, если вы используете gitlab ci.
И выполнять в нем все что вам угодно.
Я использую все эти CI за исключением appveyor. Репозиторий миррорится с gitlab.com на github.com
CI с gitlab.com самый быстрый, но не стабильный. Часто он тормозит или вообще не работает.
На остальных сервисах иногда возникают tmeout'ы.
MacOS поддерживается только Travis и если использовать свой раннер Gitlab CI (т.е. надо свой хост с macos). Платные варианты не рассматриваю.
Самба нужна только для поддержки обмена файлами между windows машинами. Т.е. самба может стоять на линукс системе, которая выполняет роль файл помойки для windows. В любых других случаях она бесполезна.
Так что критичность этой проблемы сильно преувеличена.
Если у вас всего несколько билдов, то это не большая проблема. А если их много, лучше смотреть на что-то другое чем Travis Ci.
Для gcc вы можете не использовать -msse4 и другие sse ключи компилятора, а использовать атрибут target у функции. Также можете отдать выбор по какой ветке идти с sse, avx или без для компилятора или libc, либо оставить выбор пути как у вас сейчас.
https://gcc.gnu.org/wiki/FunctionMultiVersioning
Используя препроцессор и проверку на gcc в нем, вы можете сделать что sse/avx будут работать автоматически в gcc, а для других компиляторов, надо указывать ключики.
Скажем у вас есть структура что-то вроде
a[16] для valgrind скорее всего будет корректен, если не вставится паддинг после a. А ubsan или asan выведет ошибку.
Или тоже самое, только уже разные структуры или массивы, но по указателю из первой структуры через переполнение индекса вы попадете, во вторую. Тут тоже asan/ubsan должен сработать.
Пропустить может если там будут указатели а не массивы.
Другие случаи не помню, но они тоже есть.
Еще есть более быстрый вариант. Это asan/ubsan. Он может проверять уже кое что, чего valgrind не может, но в тоже время чуть менее надежно.
Для использования *san надо собирать приложение с нужными флагами. Работа замедляется в несколько раз, но получается почти c/c++ с проверкой корректности работы с памятью.
Если по какой-то причине любая часть systemd заглючит, с большой вероятностью init процесс будет работать некорректно или упадет. если упадет init, то упадут все процессы.
Т.к. systemd лепит почти все функции в init процесс. Тоже самое с безопасностью, т.к. все части обращаются к init процессу, его могут поломать.
Еще люди пишут что при загрузке какой-то юнит может повиснуть, и значит все система уже не загрузится. Либо если какой-то юнит упадет при загрузке, будет непонятно что. Но это думаю уже зависит от криво настроенных зависимостей.
В классических init системах, init процесс запускает что-то и более ничего не делает.
Или еще одна проблема из-за systemd, теперь много софта собирается с поддержкой systemd, и не может без него работать.
На пример если взять debian, чтобы записать cd через графическое приложение, systemd обязателен. Но какое отношение systemd имеет к записи cd? Права? так можно было сослаться что нет прав на устройство.
Еще одна проблема systemd монолитность. Он включает в себе и заменяет почти все что можно. есть веб сервер, сканер штрих кодов, dns сервер и т.д. эти части сильно завязаны друг на друга, и у вас нет возможности заменить какую-то из частей systemd на альтернативы.
Другая проблема, не знаю может её уже исправили. Если при загрузке включить лог ядра, то systemd зависает или падает.
В такой конфигурации я удалил libc, но все нормально восстановилось. скопировал через sshfs и mc распакованный пакет.
1. sshfs смонтировать директорию с другого сервера.
2. открыть ssh соединение на тот сервер, откуда смонтирована директория.
3. запустить mc.
Если на текущем сервере что-то повреждается, то по ssh можно сразу сделать исправление на удаленном сервере. потом при помощи mc и sshfs скопировать на сервер с повреждением.
Можно заменить mc на busybox или еще что-то. но с mc сложнее еще раз ошибиться.