Разработчики проекта Fedora представили (http://nullr0ute.com/2012/03/an-alpha-arm-full-of-beefy-mira.../) две новые сборки дистрибутива для устройств на базе архитектур ARMv7hl (hardfp) и ARMv5tel (softfp). Первая сборка ориентирована на OMAP 3/4, IMX5, NVIDIA Tegra 2 и другие платформы на базе ARMv7. Вторая - на различные SoC на базе ARMv5 и ARMv6, например, на Marvell plugs. Разработка порта Fedora для ARM (http://fedoraproject.org/wiki/Architectures/ARM) находится на начальной стадии развития, поэтому не стоит ожидать слишком многого от первых экспериментальных сборок. Например, пока поддерживается только консольный режим работы и доступны не все пакеты из репозитория "main". Реализация GUI-интерфейса находится на стадии разработки и ожидается в ближайшее время.URL: http://nullr0ute.com/2012/03/an-alpha-arm-full-of-beefy-mira.../
Новость: http://www.opennet.me/opennews/art.shtml?num=33239
Пробовал 14 федору на арме. Вроде все нормально, софта собрано порядочно, в стандартном рутфс все есть. А сейчас в федоре и производных от нее дистрибутивах все зашкворено Поттерингом, вместо inittab даже костыли какие-то с systemd.
А что, в убунте и производных от нее inittab есть?
Как ни странно слой совместимости с init - есть. Поэтому если впадлу изучать upstart, можно просто воспользоваться классическими скриптами и не париться. И не забивать свой мозг вопросами что это сэмулировано поверх апстартовских эвентов.Но вообще - апстарт намного приятнее инита. Конфиг из пятка строк делает больше чем 2 экрана скриптовых портянок инита в куда более удобном и цивильном виде. Включая авторестарт сервиса в случае если "ему плохо", лимитированием числа таковых действий в единицу времени на случай если "ему совсем плохо", расстановкой приоритета при запуске, мониторингом наличия процесса и прочая.
Да, upstart - это довольно большой шаг вперед по сравнению с sysvinit.
Но systemd уже сейчас на голову выше upstart практически по всем фичам.Возьмем, например, мониторинг наличия процесса. Вполне нормальная и естественная для юниксовых служб привычка - форкаться. В частности, обязательно происходит двойной форк при демонизации, да и master-процесс службы может порождать подпроцессы. Корректно отследить все эти процессы без cgroups просто нельзя. А в upstart поддержки cgroups пока нет, и в обозримом будущем не будет.
> Включая авторестарт сервиса в случае если "ему плохо", лимитированием числа таковых действий в единицу времени на случай если "ему совсем плохо"А там можно, как в systemd, назначить действие при превышении лимита количества рестартов в единицу времени?
> А сейчас в федоре и производных от нее дистрибутивах все зашкворено Поттерингом, вместо inittab даже костыли какие-то с systemd.Наоборот. inittab - кривой костыль, по сравнению с простыми и прозрачными конфигами systemd.
А вот upstart, к сожалению, полностью унаследовал костыльность sysvinit и даже приумножил ее - в нем даже свой ранлевел создать нельзя.
> в нем даже свой ранлевел создать нельзя.В нем ранлевелы вообще эмулируются набором правил делающих из его нативных сущностей ранлевелы. На самом деле намного удобнее и приятнее оперировать его нативными сущностями. Скажем стартовать вебсервер по событию типа "взлетел нужный сетевой интерфейс", что очень удобно. И вообще - простая и приятная штука. Я за 10 минут накидал себе конфигов для кастомных сервисов голыми руками. Работает несколько лет, каши не просит, глюков - ноль.
> В нем ранлевелы вообще эмулируются набором правил делающих из его нативных сущностейранлевелы.
Причем этот набор правил жестко захардкоден в сишный код, и сконфигурировать его нельзя.
> Скажем стартовать вебсервер по событию типа "взлетел нужный сетевой интерфейс", что очень удобно.События запуска/готовности службы как единственная опорная точка для параллелизации - это один из ключевых design flaws upstarta. Потому что на самом деле программы-клиенты могут начинать работу раньше, чем будет готов их сервер - достаточно буферизовать их запросы. Это более логично и разумно, чем ожидать окончания запуска сервера.
Кроме того, в upstart нет и в обозримом будущем не будет поддержки сокет-активации (примитивное дублирование функциональности inetd не в счет, это не киллер-фича), например, запуск CUPS при поступлении сетевого запроса на печать. Да что там - даже привязки событиям fanotify нет, так что upstart не может запускать CUPS при появлении заданий в очереди.
> И вообще - простая и приятная штука. Я за 10 минут накидал себе конфигов для кастомных сервисов голыми руками. Работает несколько лет, каши не просит, глюков - ноль.
Лично мне не нравится, что в upstart используется свой, совершенно уникальный и неповторимый язык конфигурации, который еще надо изучать.
В systemd, например, конфигурация в формате XDG (INI), прекрасно знакомом по smb.conf, например.
> Наоборот. inittab - кривой костыль, по сравнению с простыми и прозрачными конфигами systemd.Безусловно, inittab очень уродлив. Нужно полдня по нему ман курить, и еще полдня экспериментировать, чтобы добиться вменяемого результата.
А вот с systemd все гораздо проще - достаточно к конфиге службы правильно зависимость от таргета указать. Интуитивно понятно, и без лишних извратов.
> Интуитивно понятно, и без лишних извратов.Это не unix-way.
> Нужно полдня по нему ман курить, и еще полдня экспериментировать,
> чтобы добиться вменяемого результата.Извините у Вас мозг вообще есть? Чё там вкуривать?
1. /sbin/init
2. id:5:initdefault: из /etc/inittab
3. l5:5:wait:/etc/init.d/rc 5
4. /etc/init.d/rc5.d/** - баш для ламеров с 1-ого курса Бабруйского Доярочно Слесарного Института.
---
> ... Интуитивно понятно, и без лишних извратов.Ой, звиняй, не заметил, ты же из этих, из Интуитивнопонятливых.
> Извините у Вас мозг вообще есть? Чё там вкуривать?Мозг есть. И он привык оперировать логикой, а не хаосом костылей a.k.a.
> баш для ламеров с 1-ого курса Бабруйского Доярочно Слесарного Института.Когда работаешь с sysvinit, нужно забыть про логику, и действовать исключительно методом тыка - при работе с хаотичными системами он наиболее эффективен.
> Ой, звиняй, не заметил, ты же из этих, из Интуитивнопонятливых.
Интуитивно можно понять только то, что логично и прозрачно. Удаление гланд через задницу в стиле sysvinit нелогично и поэтому интуитивно непонятно.
> Извините у Вас мозг вообще есть? Чё там вкуривать?Чтобы админить sysvinit, мозг нe нужен. Мозг нужен там, где все сделано по уму, а не от балды. А с горами костылей он неэффективен, потому что пытается найти закономерности и смысл, которых в sysvinit нет.
> А сейчас в федоре и производных от нее дистрибутивах все зашкворено Поттерингом, вместо inittab даже костыли какие-то с systemd.Вы просто завидуете, виндузятнички =)
Любой, кто пробовал настраивать inittab и systemd, в курсе, что inittab - довольно кривой и негибкий костыль. Как там, например, определить энное число кастомных ранлевелов и привязать их к аппаратным событиям, или там к fanotify?
> Вы просто завидуете, виндузятнички =)Вообще да, такое ощущение, что на Поттеринга наезжают именно виндузятники, из никсовых систем видевшие только убунту под краденой вмварью.
Чего, например, стоят вопли про "попытки ввести в *nix бинарные логи". Да в юниксах бинарные логи на критичных задачах уже лет двадцать используются, потому что текстовые шумно сдуваются на таких скоростях и размерах, как лог событий аудита, например.
на PandaBoard OMAP4 Ubuntu armhf и armel давно работают и поддерживают все фишки чипсета, как раз юзаю Ubuntu на ARM ^_^
> на PandaBoard OMAP4 Ubuntu armhf и armel давно работают и поддерживают все фишки чипсета, как раз юзаю Ubuntu на ARM ^_^А где брал PandaBoard? Как заказывал?
> на PandaBoard OMAP4 Ubuntu armhf и armel давно работают и поддерживают все
> фишки чипсета, как раз юзаю Ubuntu на ARM ^_^Убунта для арма появилась сравнительно недавно. А вот дебиан и гента там действительно сто лет в обед.
Наконец будет что поставить на Toshiba AC100, кроме глючных любительских сборок.
> Наконец будет что поставить на Toshiba AC100, кроме глючных любительских сборок.А почему именно федора, если не секрет? Дебианы, убунты, генты для арма уже давно есть.