История изменений
Исправление liksys, (текущая версия) :
Пока я писал тебе ответ, ты удалил свой камент вот с этим:
В тексте по ссылке написано следущее:
… потому что тебе очень хотелось повыпендриваться с оскорблениями, и заменил на это:
В тексте по ссылке описан какой-то дилетантизм:
Веди себя прилично. А будешь хамить - я буду просто игнорить тебя и репортить модераторам. Мне наскучило. Ты на техническом форуме, поддерживай должный уровень дискуссии.
Итак, отвечаю на твой первый вариант: в тексте написано абсолютно иное.
Далее.
Некто не осилил кросс-компиляцию
Нет. Первоначально, лет десять назад, я исследовал способы сборки ОС «изнутри», а не скриптами «снаружи», как это обычно делалось раньше. Не буду утверждать, что именно я изобрел этот способ с докером и QEMU, но точно был одним из первых, и долгое время использовал именно его. Сейчас это используется многими разработчиками IoT, и я выпустил статью, чтобы подвести некоторые итоги эксплуатации такого решения.
попытался компилировать свой софт в эмуляторе
Кросс-компиляция слабо связана с описанным процессом, хотя я пробовал и ее. Главная задача - разворачивание софта и формирование образов. То есть, сильно более поздняя стадия сборки ОС.
обвинил в своей неудаче программу qemu
И снова нет. Ты либо не читал дальше заголовка, либо ничего не понял. Цитирую:
Ну, в меньшей степени виноват QEMU… В некоторых ситуациях он сегфолтится, в других - сознательно падает с какой-то диагностикой. Это лучшее поведение, какое только можно придумать в этом случае.
Новый камент:
Что ты хотел этим сказать?
Ответом на это будет «прочитай статью целиком».
Удаленный камент:
Ты хочешь провести какую-то аналогию с systemd?
Не хочу. В статье я демонстрирую то, к чему приводит повальное использование шелл-скриптов. Классические шеллы спроектированы таким образом, чтобы замалчивать ошибки. Чтобы обрабатывать их, надо помнить вагон тонкостей и прибегать к дополнительным ключам и проверкам. В конце концов, для шелла изобрели аж целый shellcheck. В описанных случаях, постинсталл-скрипты дистрибутива фейлятся из-за QEMU, но вызывающая их часть в пакетном менеджере не обрабатывает ошибки, потому что не знает о них, так как их замолчал еще сам шелл в процессе работы.
Вывод очень простой: все сколько-нибудь длинные скрипты следует писать на более полноценных скриптовых языках - хоть на питоне, хоть на перле. В контексте systemd, он заменяет баш-портянки на универсальный оттестированный сишный код с корректной обработкой ошибок. А еще systemd-юниты более распространены, чем локальные rc-скрипты конкретного дистра, поэтому лучше оттестированы и работают в большем диапазоне технических требований без необходимости патчить сам systemd.
Исправление liksys, :
Пока я писал тебе ответ, ты удалил свой камент вот с этим:
В тексте по ссылке написано следущее:
… потому что тебе очень хотелось повыпендриваться с оскорблениями, и заменил на это:
В тексте по ссылке описан какой-то дилетантизм:
Веди себя прилично. А будешь хамить - я буду просто игнорить тебя и репортить модераторам. Мне наскучило. Ты на техническом форуме, поддерживай должный уровень дискуссии.
Итак, отвечаю на твой первый вариант: в тексте написано абсолютно иное.
Далее.
Некто не осилил кросс-компиляцию
Нет. Первоначально, лет десять назад, я исследовал способы сборки ОС «изнутри», а не скриптами «снаружи», как это обычно делалось раньше. Не буду утверждать, что именно я изобрел этот способ с докером и QEMU, но точно был одним из первых, и долгое время использовал его. Сейчас это используется многими разработчиками IoT, и я выпустил статью, чтобы подвести некоторые итоги эксплуатации решения.
попытался компилировать свой софт в эмуляторе
Кросс-компиляция слабо связана с описанным процессом, хотя я пробовал и ее. Главная задача - разворачивание софта и формирование образов. То есть сильно более поздняя стадия сборки ОС.
обвинил в своей неудаче программу qemu
И снова нет. Ты либо не читал дальше заголовка, либо ничего не понял. Цитирую:
Ну, в меньшей степени виноват QEMU… В некоторых ситуациях она сегфолтится, в других - сознательно падает с какой-то диагностикой. Это лучшее поведение, какое только можно придумать в этом случае.
Новый камент:
Что ты хотел этим сказать?
Ответом на это будет «прочитай статью целиком».
Удаленный камент:
Ты хочешь провести какую-то аналогию с systemd?
Не хочу. В статье я демонстрирую то, к чему приводит повальное использование шелл-скриптов. Классические шеллы спроектированы таким образом, чтобы замалчивать ошибки. Чтобы обрабатывать их, надо помнить вагон тонкостей и прибегать к дополнительным ключам и проверкам. В силу того, что в шелле нет нормальной системы типов, очень легко сделать трудноотлавливаемые ошибки. В конце концов, для шелла изобрели аж целый shellcheck. В описанных случаях, постинсталл-скрипты дистрибутива фейлятся из-за QEMU, но вызывающая их часть в пакетном менеджере не обрабатывает ошибки, потому что не знает о них, так как их замолчал еще сам шелл в процессе работы.
Вывод очень простой: все сколько-нибудь длинные скрипты следует писать на более полноценных скриптовых языках - хоть на питоне, хоть на перле. В контексте systemd, он заменяет баш-портянки на универсальный оттестированный сишный код с корректной обработкой ошибок. А еще systemd-юниты более распространены, чем локальные rc-скрипты конкретного дистра, поэтому лучше оттестированы и работают в большем диапазоне технических требований без необходимости патчить сам systemd.
Исправление liksys, :
Пока я писал тебе ответ, ты удалил свой камент вот с этим:
В тексте по ссылке написано следущее:
… потому что тебе очень хотелось повыпендриваться с оскорблениями, и заменил на это:
В тексте по ссылке описан какой-то дилетантизм:
Веди себя прилично. А будешь хамить - я буду просто игнорить тебя и репортить модераторам. Мне наскучило. Ты на техническом форуме, поддерживай должный уровень дискуссии.
Итак, отвечаю на твой первый вариант: в тексте написано абсолютно иное.
Далее.
Некто не осилил кросс-компиляцию
Нет. Первоначально я исследовал способы сборки ОС «изнутри», а не скриптами «снаружи», как это обычно делалось раньше. Не буду утверждать, что именно я изобрел этот способ с докером и QEMU, но точно был одним из первых, и долгое время использовал его. Сейчас это используется многими разработчиками IoT, и я выпустил статью, чтобы подвести некоторые итоги эксплуатации решения.
попытался компилировать свой софт в эмуляторе
Кросс-компиляция слабо связана с описанным процессом, хотя я пробовал и ее. Главная задача - разворачивание софта и формирование образов. То есть сильно более поздняя стадия сборки ОС.
обвинил в своей неудаче программу qemu
И снова нет. Ты либо не читал дальше заголовка, либо ничего не понял. Цитирую:
Ну, в меньшей степени виноват QEMU… В некоторых ситуациях она сегфолтится, в других - сознательно падает с какой-то диагностикой. Это лучшее поведение, какое только можно придумать в этом случае.
Новый камент:
Что ты хотел этим сказать?
Ответом на это будет «прочитай статью целиком».
Удаленный камент:
Ты хочешь провести какую-то аналогию с systemd?
Не хочу. В статье я демонстрирую то, к чему приводит повальное использование шелл-скриптов. Классические шеллы спроектированы таким образом, чтобы замалчивать ошибки. Чтобы обрабатывать их, надо помнить вагон тонкостей и прибегать к дополнительным ключам и проверкам. В силу того, что в шелле нет нормальной системы типов, очень легко сделать трудноотлавливаемые ошибки. В конце концов, для шелла изобрели аж целый shellcheck. В описанных случаях, постинсталл-скрипты дистрибутива фейлятся из-за QEMU, но вызывающая их часть в пакетном менеджере не обрабатывает ошибки, потому что не знает о них, так как их замолчал еще сам шелл в процессе работы.
Вывод очень простой: все сколько-нибудь длинные скрипты следует писать на более полноценных скриптовых языках - хоть на питоне, хоть на перле. В контексте systemd, он заменяет баш-портянки на универсальный оттестированный сишный код с корректной обработкой ошибок. А еще systemd-юниты более распространены, чем локальные rc-скрипты конкретного дистра, поэтому лучше оттестированы и работают в большем диапазоне технических требований без необходимости патчить сам systemd.
Исправление liksys, :
Пока я писал тебе ответ, ты удалил свой камент вот с этим:
В тексте по ссылке написано следущее:
… потому что тебе очень хотелось повыпендриваться с оскорблениями, и заменил на это:
В тексте по ссылке описан какой-то дилетантизм:
Веди себя прилично. А будешь хамить - я буду просто игнорить тебя и репортить модераторам. Мне наскучило. Ты на техническом форуме, поддерживай должный уровень дискуссии.
Итак, отвечаю на твой первый вариант. В тексте написано абсолютно иное.
Некто не осилил кросс-компиляцию
Нет. Первоначально я исследовал способы сборки ОС «изнутри», а не скриптами «снаружи», как это обычно делалось раньше. Не буду утверждать, что именно я изобрел этот способ с докером и QEMU, но точно был одним из первых, и долгое время использовал его. Сейчас это используется многими разработчиками IoT, и я выпустил статью, чтобы подвести некоторые итоги эксплуатации решения.
попытался компилировать свой софт в эмуляторе
Кросс-компиляция слабо связана с описанным процессом, хотя я пробовал и ее. Главная задача - разворачивание софта и формирование образов. То есть сильно более поздняя стадия сборки ОС.
обвинил в своей неудаче программу qemu
И снова нет. Ты либо не читал дальше заголовка, либо ничего не понял. Цитирую:
Ну, в меньшей степени виноват QEMU… В некоторых ситуациях она сегфолтится, в других - сознательно падает с какой-то диагностикой. Это лучшее поведение, какое только можно придумать в этом случае.
Новый камент:
Что ты хотел этим сказать?
Ответом на это будет «прочитай статью целиком».
Удаленный камент:
Ты хочешь провести какую-то аналогию с systemd?
Не хочу. В статье я демонстрирую то, к чему приводит повальное использование шелл-скриптов. Классические шеллы спроектированы таким образом, чтобы замалчивать ошибки. Чтобы обрабатывать их, надо помнить вагон тонкостей и прибегать к дополнительным ключам и проверкам. В силу того, что в шелле нет нормальной системы типов, очень легко сделать трудноотлавливаемые ошибки. В конце концов, для шелла изобрели аж целый shellcheck. В описанных случаях, постинсталл-скрипты дистрибутива фейлятся из-за QEMU, но вызывающая их часть в пакетном менеджере не обрабатывает ошибки, потому что не знает о них, так как их замолчал еще сам шелл в процессе работы.
Вывод очень простой: все сколько-нибудь длинные скрипты следует писать на более полноценных скриптовых языках - хоть на питоне, хоть на перле. В контексте systemd, он заменяет баш-портянки на универсальный оттестированный сишный код с корректной обработкой ошибок. А еще systemd-юниты более распространены, чем локальные rc-скрипты конкретного дистра, поэтому лучше оттестированы и работают в большем диапазоне технических требований без необходимости патчить сам systemd.
Исходная версия liksys, :
Пока я писал тебе ответ, ты удалил свой камент вот с этим:
В тексте по ссылке написано следущее:
… потому что тебе очень хотелось повыпендриваться с оскорблениями, и заменил на это:
В тексте по ссылке описан какой-то дилетантизм:
Веди себя прилично. А будешь хамить - я буду просто игнорить тебя и репортить модераторам. Ты на техническом форуме, должный уровень дискуссии.
Итак, отвечаю на твой первый вариант. В тексте написано абсолютно иное.
Некто не осилил кросс-компиляцию
Нет. Первоначально я исследовал способы сборки ОС «изнутри», а не скриптами «снаружи», как это обычно делалось раньше. Не буду утверждать, что именно я изобрел этот способ с докером и QEMU, но точно был одним из первых, и долгое время использовал его. Сейчас это используется многими разработчиками IoT, и я выпустил статью, чтобы подвести некоторые итоги эксплуатации решения.
попытался компилировать свой софт в эмуляторе
Кросс-компиляция слабо связана с описанным процессом, хотя я пробовал и ее. Главная задача - разворачивание софта и формирование образов. То есть сильно более поздняя стадия сборки ОС.
обвинил в своей неудаче программу qemu
И снова нет. Ты либо не читал дальше заголовка, либо ничего не понял. Цитирую:
Ну, в меньшей степени виноват QEMU… В некоторых ситуациях она сегфолтится, в других - сознательно падает с какой-то диагностикой. Это лучшее поведение, какое только можно придумать в этом случае.
Новый камент:
Что ты хотел этим сказать?
Ответом на это будет «прочитай статью целиком».
Удаленный камент:
Ты хочешь провести какую-то аналогию с systemd?
Не хочу. В статье я демонстрирую то, к чему приводит повальное использование шелл-скриптов. Классические шеллы спроектированы таким образом, чтобы замалчивать ошибки. Чтобы обрабатывать их, надо помнить вагон тонкостей и прибегать к дополнительным ключам и проверкам. В силу того, что в шелле нет нормальной системы типов, очень легко сделать трудноотлавливаемые ошибки. В конце концов, для шелла изобрели аж целый shellcheck. В описанных случаях, постинсталл-скрипты дистрибутива фейлятся из-за QEMU, но вызывающая их часть в пакетном менеджере не обрабатывает ошибки, потому что не знает о них, так как их замолчал еще сам шелл в процессе работы.
Вывод очень простой: все сколько-нибудь длинные скрипты следует писать на более полноценных скриптовых языках - хоть на питоне, хоть на перле. В контексте systemd, он заменяет баш-портянки на универсальный оттестированный сишный код с корректной обработкой ошибок. А еще systemd-юниты более распространены, чем локальные rc-скрипты конкретного дистра, поэтому лучше оттестированы и работают в большем диапазоне технических требований без необходимости патчить сам systemd.