И не надо лукавить, что конкретно читатель не идет на stackoverflow или github issues за готовым ответом или направлением, куда рыть, а тратит кучу времени чтобы найти баг самостоятельно, разрыв весь программный продукт, перечитав всю документацию от корки до корки и т.д.) Не поверю.
А кто будет отвечать на Stackoverflow, если никто не изучает маны, а только ищет готовые ответы на тот же stackowerflow? Откуда берутся новые правильные ответы?
Готового решения может не быть.
Что-то не было решений, когда я коммитил в buildroot. Как и нет решений для kernel developer, приходится им самим их создавать.
Про оптимизацию под железо вообще классно. Особенно во встраиваемых системах. А уж как изгаляются крутые вендоры для прохождения spec cpu(сейчас spec Cpu2000) теста, например. Рекомендую почитать. Так вот, этот тест компилируется на месте под систему. И от этого сильно зависит результат. Этим тестом пользуются и hp, и dell, и прочие. рекомендую к изучению(учеба ради учебы :-D ).
Помню эпичный случай, когда ключевое ПО тормозило, тормозя все остальные проекты. И что мы сделали? Пересобрали его с правильной оптимизацией. И всё залетало.
Без умения в нужных местах оптимизировать будем в каждую микроволновку пихать xeon и 32 гига оперативки.
Почему-то все понимают необходимость тюнить postgerss на серьезных нагрузках, а вот ядро оптимизировать или правильно компилить это уже устарело, надо же.
сейчас просто не нужно знать как поставить кде под фрибсд.
А вот тут в корне не согласен! Кто-то должен знать, Что бы собрать в deb/rpm/иной прекомпилированный пакет или написать ebuild. Тут всё просто — собирать из исходников надо уметь.
Если у тебя есть конкретный кейс который надо решить, ты идешь в гугл, который первой ссылкой дает тебе ответ
Только если не будет тех кто учится жестко и глубоко, то откуда возьмется гугл? Сколько раз наблюдал кусочные решения: Тут нагуглил, там нагуглил, в итоге жуткий монстр франкенштейна. А всё что нужно было, это изучить нормально и сделать одно красивое решение.
Очень часто сейчас люди не хотят заморачиваться на «сложности». В итоге компануют 100500 «простых решений», в результате получают ещё больше проблем. И начинают мужественно бороться с этими проблемами. Это как отрезать себе обе ноги, что бы не учиться бегать, а сразу ездить в коляске.
Как я и писал — важнее прямые руки и голова…
И я не утверждаю., что начинать нужно только с них.
Но статистика неумолима. Так или иначе прошедшие gentoo/arch/lfs показывают лучшие результаты. Не важно, было это в начале их пути или нет.
Очень печально, что начавшие сразу с лёгкого очень редко идут раньше. Но при этом зачастую позиционируют себя как серьёзных, дорогих специалистов. И ведут мнение о Linux и вообще его развитие не в ту сторону.
Вполне дружелюбны. Только люди не готовы к разнообразию и возможностям. А ещё эффект утёнка.
Linux построен на свободе и возможностях, а не «жри что дали».
Пример. Моей матери гораздо проще и удобнее работать в XFCE/KDE, чем в винде. Точнее, на виндах ей не удобно и она этого избегает.
В той статье ИМХО автор не понял философию Linux. Свобода и возможности, пользуйся правильно.
PS знакомый виндовый разраб (стаж 20+ лет) заметил, что автор видать под windows не писал. там тоже проблем хватает с библиотеками, а уж про решение проблем(логи хотя бы нормальные) вообще лучше молчать.
Ох уж этот образ красноглазых! неверный стереотип.
Основная масса серьёзных линуксоидов, которых я знаю лично — весьма спокойные, гармонично развитые люди. Так и не поймешь по внешнему виду, кем работают.
А когда вижу футболки и прочую атрибутику(особенно бубен), то в 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.
Ваш комментарий не имеет отношения к статье.
А кто будет отвечать на Stackoverflow, если никто не изучает маны, а только ищет готовые ответы на тот же stackowerflow? Откуда берутся новые правильные ответы?
Готового решения может не быть.
Что-то не было решений, когда я коммитил в buildroot. Как и нет решений для kernel developer, приходится им самим их создавать.
Про оптимизацию под железо вообще классно. Особенно во встраиваемых системах. А уж как изгаляются крутые вендоры для прохождения spec cpu(сейчас spec Cpu2000) теста, например. Рекомендую почитать. Так вот, этот тест компилируется на месте под систему. И от этого сильно зависит результат. Этим тестом пользуются и hp, и dell, и прочие. рекомендую к изучению(учеба ради учебы :-D ).
Помню эпичный случай, когда ключевое ПО тормозило, тормозя все остальные проекты. И что мы сделали? Пересобрали его с правильной оптимизацией. И всё залетало.
Без умения в нужных местах оптимизировать будем в каждую микроволновку пихать xeon и 32 гига оперативки.
Почему-то все понимают необходимость тюнить postgerss на серьезных нагрузках, а вот ядро оптимизировать или правильно компилить это уже устарело, надо же.
А вот тут в корне не согласен! Кто-то должен знать, Что бы собрать в deb/rpm/иной прекомпилированный пакет или написать ebuild. Тут всё просто — собирать из исходников надо уметь.
Только если не будет тех кто учится жестко и глубоко, то откуда возьмется гугл? Сколько раз наблюдал кусочные решения: Тут нагуглил, там нагуглил, в итоге жуткий монстр франкенштейна. А всё что нужно было, это изучить нормально и сделать одно красивое решение.
Очень часто сейчас люди не хотят заморачиваться на «сложности». В итоге компануют 100500 «простых решений», в результате получают ещё больше проблем. И начинают мужественно бороться с этими проблемами. Это как отрезать себе обе ноги, что бы не учиться бегать, а сразу ездить в коляске.
И я не утверждаю., что начинать нужно только с них.
Но статистика неумолима. Так или иначе прошедшие gentoo/arch/lfs показывают лучшие результаты. Не важно, было это в начале их пути или нет.
Очень печально, что начавшие сразу с лёгкого очень редко идут раньше. Но при этом зачастую позиционируют себя как серьёзных, дорогих специалистов. И ведут мнение о Linux и вообще его развитие не в ту сторону.
Хочешь быть профи — учись нормально
Linux построен на свободе и возможностях, а не «жри что дали».
Пример. Моей матери гораздо проще и удобнее работать в XFCE/KDE, чем в винде. Точнее, на виндах ей не удобно и она этого избегает.
В той статье ИМХО автор не понял философию Linux. Свобода и возможности, пользуйся правильно.
PS знакомый виндовый разраб (стаж 20+ лет) заметил, что автор видать под windows не писал. там тоже проблем хватает с библиотеками, а уж про решение проблем(логи хотя бы нормальные) вообще лучше молчать.
Основная масса серьёзных линуксоидов, которых я знаю лично — весьма спокойные, гармонично развитые люди. Так и не поймешь по внешнему виду, кем работают.
А когда вижу футболки и прочую атрибутику(особенно бубен), то в 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.
Ваш комментарий не имеет отношения к статье.
Исчерпывающее сведения, что где должно лежать. Стандарт