Релиз Buildroot 2012.05

Поддержка платформы Microblaze

Годно.

Добавлены 34 «пакета» для сборки ПО в т.ч. ... systemd

systemd на embedded? это уже перебор, товарищи.

хорошая штука

systemd на embedded? это уже перебор, товарищи.

Просто интересно, а чем тебя не устраивает systemd?

Логика работы systemd как раз таки больше подходит к embedded чем классический init.

Просто интересно, а чем тебя не устраивает systemd?

На embedded наблюдение и отладка процесса загрузки довольно полезная вещь. Да и dbus мне там совершенно ни к чему.

Да и вообще я приверженец unix-way и KISS, противник сложных комбайнов (не считая emacs :) ).

Да и вообще

думаю это слишком субъективно

А что мешает наблюдать и отлаживать процесс загрузки с использованием systemd?

Да, это я упустил.

unix-way это как раз таки отделение сцщностей друг от друга на небольшие утилиты/демоны, которые между собой взаимодействуют и этим взаимодействием как-то управляют железкой. А DBUS лишь позволяет общаться между собой сообщениями по шине, что выглядит вполне удобно.

Удобно, да. Но если ресурсов немного, то можно общаться и с помощи обычных unix-сигналов.

Если нужно завязывать web-интерфейс, библиотечку для управления внешними железками, демон для управления светодиодами на основе статистики собираемой с gsm/wifi модулей и запуск/остановку сетевых сервисов, то поневоле задумаешься о том, что на unix-socket/posixmq/signals - это всё завязывать мягко скажем сложновато и велосипед получается уж очень похож то ли на шину данных, то ли на MQ.

В данном случае согласен. Выгоды в ресурсах не будет никакой, а логика заметно усложнится.

systemd на embedded? это уже перебор, товарищи.

В OpenEmbedded systemd давно был уже, Buildroot просто догнал.

Хорошая штука, жалко нет пэкедж менеджмента

Хорошая штука, жалко нет пэкедж менеджмента

Есть на этапе сборки образа =)

+1

Почему же? Можно собрать ipkg или rpm, для embedded вполне достаточно. Другое дело, что внутренней поддержки для них нет, но поскольку в большинстве железок rootfs в ro из-за того, что всё друг к другу прибито гвоздями, то обновлять по отдельности пакеты смысла не имеет, если уж обновлять, то сразу весь rootfs

которые между собой взаимодействуют

Взаимодействуют, ага. А не взаимозависят. Привязать систему инициализации к другому демону - это немножко неправильно.

моё мнение, что DBUS вообще пора запилить в ядро, чтобы была единообразная возможность гонять сообщения между процессами не завися от сторонних демонов.

А DBUS лишь позволяет общаться между собой сообщениями по шине, что выглядит вполне удобно.

Я стронник такой шины, но этот ваш DBUS выглядит как ява или с# с их бесконечными org.common.someshit.uselessmodule.garbage

Может и тебя запилить в ядро? Так, на всякий случай.

Ну а чо? буду себе прерывания гонять, да порнуху в траффике искать

Сгинь, тролль!

Забористые вещества :)

Ты первый начал.

Нет ты. Я ответил на последнее твоё троллосообшение.

Это кстати не было троллоло, я был вполне серьзен. Ладно, не d-bus, но вменяемый протокол message-oriented IPC. Как в микроядрах.

Еще чуть-чуть, и ты запилишь в ядро вывод графики, получив, наконец, долгожданную Windows NT. ;)

мне как работающему с embedded графика в ядре нафиг не нужна. Как и множество других фич. Это Шаттлворт пилит десктоп, пусть он и впиливает.

Поддержка стороннего тулчейна от Linaro для ARM-архитектуры

Вроде ж уже есть, кажется, давно, с 2011.3... или Линаро ещё что-то запилило?

Можно, но пакеты сам билдрут собирать не умеет.

Там Codesourcery было и есть.

Хорошая штука, жалко нет пэкедж менеджмента

а почему я там видел галочку поддержки opkg в меню конфигурации buildroot?..

А ты ее не пробовал выбирать?

Я пробовал. почему ненужно - см. выше.

минорщина же, если бы они hurd написали... а так...

у buildroot релиз это достаточно формальная вещь. Примерно так же как у wine. Так что минорщина-не минорщина - решать модераторам.

a ya tupoi i ne ponial ni chego (

кросс-тулчейн

Я аж икнул.

Будешь икать когда сам его руками собирать будешь. Там икается много и долго.

Ну не знаю, как по мне, то самописный Makefile как то проще и надёжнее.
Сейчас начали работать с FreeScale, так что-то используемый там ltib пока особо не впечатляет. Толи дело SDK от TexasInstrumrnts с прозрачным Makefile.

используя uclibc/eglibc/glibc библиотеку

Английский порядок слов. Либо «используя библиотеку ././.», либо вообще без библиотеки.

Поэкспериментировать, что ли. Полезный должен быть опыт.

думаю это слишком субъективно

Зато !@#$^Wпаладины поттеринга блещут объективностью: забыть про dbus, оставить удобное и, сидя на белом коне, отвергнуть последнее.

если бы они hurd написали

странно от человека с зебросвиньёй такое слышать, вот кто-кто, а exherbo точно некрофилией не занимаются )

паладины поттеринга

Ну я пока сижу на openrc лишь потому, что паладины плохо выполняют свою работу, и тут и там проблемы совместимости, никто не любит этих паладинов.

Еще чуть-чуть, и ты запилишь в ядро вывод графики, получив, наконец, долгожданную Windows NT

Классическая NT никакой графики в ведре не имела. M$ это паскудство начали творить кажысь с W2000.

Будешь икать когда сам его руками собирать будешь. Там икается много и долго.

Много икалось во времена glibc 2.3.6 и gcc переходного периода 3.x -> 4.x. Сейчас glibc-based тулчейн собирается с минимальной доработкой напильником.

когда я последний раз собирал тулчейн полностью руками, года два назад, мне икалось.