Ох уж этот образ красноглазых! неверный стереотип.
Основная масса серьёзных линуксоидов, которых я знаю лично — весьма спокойные, гармонично развитые люди. Так и не поймешь по внешнему виду, кем работают.
А когда вижу футболки и прочую атрибутику(особенно бубен), то в 99% это неофит, который ничего толком не знает и знать не хочет. Он смог поставить убунту(да да далее) и считает себя крутым. Их предел: «винда гуано, линукс рулез». Точка.
Если не развивать популяцию серьезных людей(читающих, пишущих и знающих), то весь этот чудный мир загнется. Некому будет развивать.
maquefel и говорит, что ну его нафиг, эту популяризацию. Не туда это привело нас. Вместо роста получаем падение уровня среднего линуксоида. И что хуже — сокращение популяции серьезных специалистов.
В целом согласен, сейчас сам с этим столкнулся. Но это если речь о больших корпорациях, в которых офисные/web сценарии (условно).
Промышленная автоматизация и встраиваемые системы отличаются. Там реально может потребоваться самое свежее, потому что в нем меньше ошибок. И под собранную под себя (на будущий девайс) ОС.
При сборке в том же buildroot убеждался не раз, что свежая версия спасает от проблем.
Огромное спасибо нужно сказать подобным статьям, в которых незнание автора смешивается с клеветой, которое потом будет раз за разом повторяться, обрастая новыми искажениями.
In addition, LTSP uses the nfs / nbd protocol. I don't like when network connection dependencies work on my system.
HTTP and FTP allows booting ALL systems from rootfs to my client. Then my system will be offline.
I guess LTSP is a complete solution for network boot. But in my practice wa are don works without it.
My article is more than pxe tutorial. I tried to show how to customize ubuntu boot to use ubuntu as firmware from squashfs. PXE is only one of variant
систему ROS2, подходящую для более «рукастых» разработчиков
Поподоробнее хотелось бы. Чем ROS2 лучше для «рукастых»? Я вижу только эволюцию проекта.
Про REAL-TIME соглашусь, всё таки real-time ОС это отдельное явления. А здесь я вижу framework. Как я понимаю, они хотят спортироваться на real-time ОС вроде vxWorks, qnx? Интересно стало, на свежую голову пожалуй перечитаю.
I glad to hear it!
Web-interface really simple — some PHP for frontend and bash scripts in backend. Auth via lighttpd module.
A don't like to develop any gui, including web). In addition, i don't like big interfaces. Bad way: write 100+ Mb web-interface for 60mb OS.
Поясню, что и зачем применялось.
Выбор final.target и свои target — для выбора режима загрузки — live-диск, инсталлятор, нормальная работа. А также для удобной группировки своих скриптов.
Интерактивный скрипт включения — инсталлятор должен иметь возможность взаимодействовать с пользователем.
Интерактивный скрипт выключения — редко, но потребовалось запросить подтверждение от пользователя на выполнение обновления.Потому что так захотел заказчик.
Zabbix и postgresql вполне могут жить на встроенной системе. Не вижу противоречия. Собственно, такую прошивку я и описывал в другой статье — arm(2 разных платы)/x86_64 с zabbix-server и web-интерфейсом для управления.
Моё ИМХО — думать надо что, где и как применять. Мне не приходит в голову делать скрипт запуска веб-сервиса интерактивным, не попадалось таких задач. Но инсталлятор ОС в консольном режиме — его придётся делать интерактивным.
Если не устраивает организационная сторона — лучше взять самому за ситуацию. Проблемы с процедурой — пишите и пробивайте новую. НО проблемы с организацией это не повод ненавидеть те или иные технические решения.
Ну, обновлять ночью без присмотра, своими скриптами…
А что мешает написать скрипт с параметрами автоматической установки? Или параметр, указывающий файл с конфигурацией установки? Я не говорю про Tk/Tcl.
Ваш комментарий не имеет отношения к статье.
maquefel подал не плохую мысль.
Действительно, если Вы начнёте писать статью по этой теме, то это даст хороший рост. Объяснить кому-то всегда сложнее, чем взять и сделать.
Я поэтому и начал писать про buildroot. Хорошая систематизация знаний и мозный стимул начать разбираться как следует
мой опыт:
1.roofs_overlay. Удобно когда нужно иметь файл гарантированного содержания. Который не поменяется с обновлением версий.Наглядно, понятно, новый в проекте человек сходу всё видит и понимает. Ну и порядок- сразу видно, какой файл куда попадёт.
2. Вариант со скриптами. Удобно, что можно прогнать sed/awk и внести изменения в любой конфиг, который может поменяться с обновлением пакета.Я тоже так делаю.
Насчет обновления buildroot, удобно хранить в external_tree свои наработки. Это избавляет лишней работы.
Насчет прав, есть механизм BR2_ROOTFS_DEVICE_TABLE. Он позвоялет создавать файлы( в тч устройств) с нужными правами.Можно менять права на имеющиеся файлы, насколько я понял. Детально ещё не пробовал с ним работать.
Обо всех этих механизмах в дальнейших статьях напишу. Две уже готовы, ещё 2 надо дописать.
В итоге я использую оба метода. Они оба хороши по-своему.
О создании полноценной конфигурации платы, external tree и прочем — в следующей статье. От простого с ложному.
Команды «save-update-defconfig» не существует. Наверно, имелось ввиду " make linux-update-defconfig"?
Скелет файловый системы — не хотелось бы путаницы со skeleton. Так-то output/target и не совсем скелет. Это файловая система, в которой отсутвуют только файлы устройств(/dev ) и не настроены правана файлы.
Основная масса серьёзных линуксоидов, которых я знаю лично — весьма спокойные, гармонично развитые люди. Так и не поймешь по внешнему виду, кем работают.
А когда вижу футболки и прочую атрибутику(особенно бубен), то в 99% это неофит, который ничего толком не знает и знать не хочет. Он смог поставить убунту(да да далее) и считает себя крутым. Их предел: «винда гуано, линукс рулез». Точка.
Если не развивать популяцию серьезных людей(читающих, пишущих и знающих), то весь этот чудный мир загнется. Некому будет развивать.
maquefel и говорит, что ну его нафиг, эту популяризацию. Не туда это привело нас. Вместо роста получаем падение уровня среднего линуксоида. И что хуже — сокращение популяции серьезных специалистов.
Потреблять не сложно, не то что создавать.
Промышленная автоматизация и встраиваемые системы отличаются. Там реально может потребоваться самое свежее, потому что в нем меньше ошибок. И под собранную под себя (на будущий девайс) ОС.
При сборке в том же buildroot убеждался не раз, что свежая версия спасает от проблем.
лучше не скажешь. только «спасибо» в кавычках
Yes, you must run update-repo.sh for meta-file generation (Packages, Packages.gz and signs)
HTTP and FTP allows booting ALL systems from rootfs to my client. Then my system will be offline.
My article is more than pxe tutorial. I tried to show how to customize ubuntu boot to use ubuntu as firmware from squashfs. PXE is only one of variant
Поподоробнее хотелось бы. Чем ROS2 лучше для «рукастых»? Я вижу только эволюцию проекта.
Про REAL-TIME соглашусь, всё таки real-time ОС это отдельное явления. А здесь я вижу framework. Как я понимаю, они хотят спортироваться на real-time ОС вроде vxWorks, qnx? Интересно стало, на свежую голову пожалуй перечитаю.
Web-interface really simple — some PHP for frontend and bash scripts in backend. Auth via lighttpd module.
A don't like to develop any gui, including web). In addition, i don't like big interfaces. Bad way: write 100+ Mb web-interface for 60mb OS.
But, if you need, i will write short for you.
Насчет списка литературы поддержу.
А так — спасибо за статью
Выбор final.target и свои target — для выбора режима загрузки — live-диск, инсталлятор, нормальная работа. А также для удобной группировки своих скриптов.
Интерактивный скрипт включения — инсталлятор должен иметь возможность взаимодействовать с пользователем.
Интерактивный скрипт выключения — редко, но потребовалось запросить подтверждение от пользователя на выполнение обновления.Потому что так захотел заказчик.
Zabbix и postgresql вполне могут жить на встроенной системе. Не вижу противоречия. Собственно, такую прошивку я и описывал в другой статье — arm(2 разных платы)/x86_64 с zabbix-server и web-интерфейсом для управления.
Если не устраивает организационная сторона — лучше взять самому за ситуацию. Проблемы с процедурой — пишите и пробивайте новую. НО проблемы с организацией это не повод ненавидеть те или иные технические решения.
А что мешает написать скрипт с параметрами автоматической установки? Или параметр, указывающий файл с конфигурацией установки? Я не говорю про Tk/Tcl.
Ваш комментарий не имеет отношения к статье.
Исчерпывающее сведения, что где должно лежать. Стандарт
Действительно, если Вы начнёте писать статью по этой теме, то это даст хороший рост. Объяснить кому-то всегда сложнее, чем взять и сделать.
Я поэтому и начал писать про buildroot. Хорошая систематизация знаний и мозный стимул начать разбираться как следует
1.roofs_overlay. Удобно когда нужно иметь файл гарантированного содержания. Который не поменяется с обновлением версий.Наглядно, понятно, новый в проекте человек сходу всё видит и понимает. Ну и порядок- сразу видно, какой файл куда попадёт.
2. Вариант со скриптами. Удобно, что можно прогнать sed/awk и внести изменения в любой конфиг, который может поменяться с обновлением пакета.Я тоже так делаю.
Насчет обновления buildroot, удобно хранить в external_tree свои наработки. Это избавляет лишней работы.
Насчет прав, есть механизм BR2_ROOTFS_DEVICE_TABLE. Он позвоялет создавать файлы( в тч устройств) с нужными правами.Можно менять права на имеющиеся файлы, насколько я понял. Детально ещё не пробовал с ним работать.
Обо всех этих механизмах в дальнейших статьях напишу. Две уже готовы, ещё 2 надо дописать.
В итоге я использую оба метода. Они оба хороши по-своему.
Поправил, добавил использование команды linux-update-defconfig
Спасибо за комментарий.
Команды «save-update-defconfig» не существует. Наверно, имелось ввиду " make linux-update-defconfig"?
Скелет файловый системы — не хотелось бы путаницы со skeleton. Так-то output/target и не совсем скелет. Это файловая система, в которой отсутвуют только файлы устройств(/dev ) и не настроены правана файлы.