А то что другие дистры не могут без их кода свои дистры развивать и тащат к себе это все это

По-моему, Red Hat просто угрожает разработчикам остальных дистрибутивов. И только бравые гентушники осмелились противостоять этой корпорации зла.

По-моему, Red Hat просто угрожает разработчикам остальных дистрибутивов.

Конечно, посылает штурмовые отряды в дома разработчиков. Пруфы на твои влажные фантазии будут?

Тащат к себе потому что удав.

Пруфы на твои влажные фантазии будут?

Это всего лишь моё предположение, пруфов нет и не будет.

и истерично убеждает остальных не только лопату выкинуть но и свернуть производство лопат

скорее куча истеричек кричит, что лопата - это священное орудие труда.

Хорошо, как только тебе начнет угрожать Red Hat - не забудь отписаться здесь.

Я не разрабатываю дистрибутивы и неинтересен редхатовцам.

И только бравые гентушники осмелились противостоять этой корпорации зла.

> eix -Ic openrc                      
[I] sys-apps/openrc (0.11.8[1]@04.02.2013): OpenRC manages the services, startup and shutdown of a host
> eix -Ic systemd
[I] sys-apps/systemd (9999{tbz2}@07.03.2013): System and service manager for Linux
> eix -Ic upstart
Совпадений не найдено.

100% :D

Canonical - не менее зло, чем Red Hat.

скорее куча истеричек кричит, что лопата - это священное орудие труда.

Угу.

- Если вы не понимаете принципов инженерии сами и не верите нам - вот отсылка к авторитетам: «простота фундаментальный инженерный принцип»
- Это культ священной лопаты - и он фундаменталистский, вы сами только что сказали!

«простота фундаментальный инженерный принцип» [1]

Ты же понимаешь, что без формальных критериев и анализа соответствия проекту задания этим критериям под простоту можно подбить вообще что угодно.

Например. Так как [1], то декомпозиция большого объекта на 100500 маленьких со слабой связанностью есть правильный подход, так как мы получаем 100500 маленьких простых компонентов, которые будут надежнее, так как а) используются в других компонентах, следовательно ошибки будут выявлены на раннем уровне б) проще написать тесты для отдельных компонент в) проще проводить аудит кода с) проще отлаживать в местах стыков

Или же. Так как [1], то декомпозиция большого объекта на 100500 маленьких со слабой связанностью есть неправильный подход, так как мы раздуваем систему ненужными абстракциями, которые не будут в полной мере востребованы, и экспоненциально увеличиваем количество клея, который не будет должным способом протестирован, тем самым выполняя ненужные усложнения, так как конечная цель нашего проекта - построения фронтенда для решения ряда конкретных задач, а не пополнение рядов фреймворков еще одним

- Если вы не понимаете принципов инженерии сами и не верите нам - вот отсылка к авторитетам: «простота фундаментальный инженерный принцип»

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

- Это культ священной лопаты - и он фундаменталистский, вы сами только что сказали!

Для меня это всего лишь инструменты.

Попробую пример

Очень много написали ....

Есть контора, которая делает некоторое железо с *nix на борту. Пусть это будет http://qnap.ru/ts-410. Просто в железках для авто или в TV я не ковырялся. В целях ознакомления у конторы QNAP есть заход через веб на какой-то накопитель, только адрес не помню, думаю, что если кому интересно, то найдет.

Внутри этого железа есть флеш-диск, с которого она грузится. Диски (HD) там рекомендуют держать в каком-нибудь RAID, который реализован через md. В принципе грузиться может и с раздела диска и/или раздела RAID - ну простому потому, что там кроме обычного linux ничего нет.

Есть процедура обновления «прошивки». Забирается архив с официального сайта и «устанавливается» на флеш. В архиве загрузочный раздел и рутовая ФС. Что-то свое добавить туда нет возможности.

Все управление «сервисами» данной железки реализовано через веб-морду.

Конфигурация хранится в специальном разделе на флеш. Есть две бинарные команды, которые реализуют прочитать/записать конфиг.

Раскрутка системы идет так: после загрузки ядра корень ФС создается в оперативной памяти и с помощью init-скиптов создаются симлинки на всякое разное нужное из /bin, /usr/bin /sbin и так далее. Каталог /etc пересоздается при загрузке. В конце всего этого выполняется скрипт по фиксированному пути из раздела RAID, в который и надо вставлять всякие левые софтинки.

Прцесс загрузки и раскрутки естественно нигде не описан.

Теперь о чем пример.

В одном из предыдущих предложения я написал «сервисами» в кавычках неслучайно. Это обыные демоны. Стандартно их совсем немного. Сразу возникает желание что-то добавить. Первое - это качалка для торентов, которой долго не было среди «поддерживаемоего» софта. И по понятным причинам :)

Только вот кого из сервисов запускать и с какими параметрами записано в конфиге, на который не посмотришь до тех пор, пока не поймешь как железка устроена. Управление идет через веб путем запуска CGI, которые являются бинарниками. Не пыхпых и даже не ява. То есть не получится быстро понять, как это работает. Помогают здесь наличие шеловских init-скриптов.

Если в эту железку запихают systemd, то скриптов после этого не останется совсем. Будут написаня на C юниты, а исходники никому не положены, потому как защищены авторским правом.

Фактически для встроенных систем намечается ситуация, из-за которой начался весь проект GNU. И об этом в одном из прошлых обсуждений кто-то уже писал.

Ты же понимаешь, что без формальных критериев и анализа ...

Угу. Только слово «формальные» тут тоже нужно применять с головой а не формально. Формальные критерии как и инженерные принципы(включая юниксвей) тоже работают только в умелых руках.

Например. Так как [1], то декомпозиция большого объекта ...
Или же. Так как [1], то декомпозиция большого объекта....

И вот теперь найди мне еще тут комменты от сторонников системд на тему того что они, хотя бы неявно, признают само наличие этих фундаментальных принципов инженерии. Более того ты лично хоть и признаешь наличие некоторых инженерных принципов юниквея(а это набор инженерных принципов) не признаешь и рассказываешь про то что устарели :D

И с моей точки зрения если человек в споре ведет себя так как будто принципиально отрицает наличие фундаментальных инженерных принципов - мнение такого человека относительно systemd *абсолютно* нерелевантно. И этот человек - идиот, при чем в данном случае это будет ярлык повешенный на человека по абсолютно формальным, объективным критериям. Человек который на указание «системд не юниксвейный(см набор принципов)» отвечает «мне всеравно и юниксвей устарел» - это идиот.

Если же у нас практически все сторонники системд - идиоты, то я не вижу у этого решения, собственно, сторонников.

PS
И да - вот сейчас пример творящегося с Хксами ужаса - наглядный пример того к чему приводит пренебрежения принципами юниксвея. «Дада» говорили авторы Х, «этот ваш юниксвей усторел!» когда его писали. Да, система получилась модульной - но недостаточно модульной.

И как то так получается по естественным причигам что *любой* крупный свободный софт рискует получить 2-3 ментейнера на всю огромную кодебазу. После чего 90-е и 2000-е в системе происходит песец - который прекрасно расписан в лекциях тех самых одиноких ментейнеров Х, авторов вейленда.

В результате - неюниксвейные программы просто не выживают на long run. Проблема в том что для того что бы оценить long run нужно знать историю и делать из нее выводы. А не быть дебильной школотой ;D

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

Вот тут вы либо настолько глупы что не понимаете аргументов собеседника, либо передергиваете в хамской форме.

Для меня это всего лишь инструменты.

И что из этого следует? Вы оцениваете все эти инструменты по определенным критериям. И ваш список критериев оценки инструмента однозначно характеризует вас как человека не обладающего необходимой квалификацией для высказывания суждений по поводу архитектуры системного ПО.

Помогают здесь наличие шеловских init-скриптов.
Если в эту железку запихают systemd, то скриптов после этого не останется совсем

Вообще говоря классические init скрипты (не уверен как сейчас с LSB хедерами) прекрасно можно реализовать в виде бинарей. Собственно не сложнее чем юниты systemd.

И вкомпилирован статически?

Динамически, а какая разница?

Вообще говоря классические init скрипты (не уверен как сейчас с LSB хедерами) прекрасно можно реализовать в виде бинарей. Собственно не сложнее чем юниты systemd.

Для выполнения бинаря ядро должно создать процесс, то есть построить таблицы в памяти, открыть файл с кодом и прочитать по крайней мере одну страницу с точкой входа.

Для выполнения шеловского скрипта нужно создать процесс, отрыть файл и прочитать код шела, открыть файл со скриптом.

Только вот код шела часто используется и потому скорее всего в памяти и его читать не придется. Бинарь может дать выигрыш по скорости выполнения. А чем производительнее железо, тем этот выигрыш минимальнее.

Если короче: а зачем делать бинарь ?

И вкомпилирован статически?

Динамически, а какая разница?

Тогда причем здесь

true_admin> Сам dbus тоже монструозен.

? Сколь бы dbus не был монструозен, в почти метре бинаря systemd его нет.

Сколь бы dbus не был монструозен, в почти метре бинаря systemd его нет.

А почему это так важно? Для меня главное что ключевые куски системы очень большие. Какая разница один бинарь или несколько? Всё равно это часть одной системы.

Если короче: а зачем делать бинарь ?

Из описанных вами целей злодейства - затем, за тем же что бы писать бинарные юниты systemd.

Сколь бы dbus не был монструозен, в почти метре бинаря systemd его нет.

А почему это так важно?

Напомню контекст:

tailgunner> 900к для движка зависимостей и интерфейса к DBus - это как-то слишком дофига.

true_admin> Сам dbus тоже монструозен.

Мне интересно, какая такая могучая логика зашита в systemd, что там под метр кода? В make - 142к, в /sbin/init - смешные 32к.

Какая разница один бинарь или несколько?

Fault containment. То, что сегфолт в journald или localed не валит systemd - это хорошо.

Угу. Только слово «формальные» тут тоже нужно применять с головой а не формально. Формальные критерии как и инженерные принципы(включая юниксвей) тоже работают только в умелых руках.

Гениально

Более того ты лично хоть и признаешь наличие некоторых инженерных принципов юниквея(а это набор инженерных принципов) не признаешь и рассказываешь про то что устарели :D

Так я признаю некоторые инженерные принципы юниксвея или не признаю некоторые инженерные принципы юниксвея?

И с моей точки зрения если человек в споре ведет себя так как будто принципиально отрицает наличие фундаментальных инженерных принципов - мнение такого человека относительно systemd *абсолютно* нерелевантно. И этот человек - идиот, при чем в данном случае это будет ярлык повешенный на человека по абсолютно формальным, объективным критериям. Человек который на указание «системд не юниксвейный(см набор принципов)» отвечает «мне всеравно и юниксвей устарел» - это идиот.

Ну, мы знаем, что посетителей храмов думают о глупцах атеистах :]

Вообще, у тебя кажется какая-то фобия по поводу того, что твои собеседники не признают некие ФУНДАМЕНТАЛЬНЫЕ заповеди. С чего ты это вообще взял - совершенно не ясно.

И да - вот сейчас пример творящегося с Хксами ужаса - наглядный пример того к чему приводит пренебрежения принципами юниксвея. «Дада» говорили авторы Х, «этот ваш юниксвей усторел!» когда его писали. Да, система получилась модульной - но недостаточно модульной.

But perhaps the most enduring objections to Unix are consequences of a feature of its philosophy first made explicit by the designers of the X windowing system. X strives to provide “mechanism, not policy”, supporting an extremely general set of graphics operations and deferring decisions about toolkits and interface look-and-feel (the policy) up to application level. Unix's other system-level services display similar tendencies; final choices about behavior are pushed as far toward the user as possible. Unix users can choose among multiple shells. Unix programs normally provide many behavior options and sport elaborate preference facilities. (AoUP/1.4)

Ты уверен, что подумал?

Мне интересно, какая такая могучая логика зашита в systemd, что там под метр кода? В make - 142к, в /sbin/init - смешные 32к.

http://bpaste.net/show/82441/

Большая часть - надстройки над стандартной библиотекой и логика управления зависимостями

> strings /bin/systemd > /tmp/strings; du -h /tmp/strings
284K	/tmp/strings

Итд

Теперь о чем пример.

Пример о том, что у QNap есть шелл скрипты. А в других поделках есть патченый бизибокс, патченый дропбокс и куча левых бинарников, просто запуская которые получаешь сегфолт. И что? Если везде будет родной системде, ситуация различаться не будет. А если будет воля к огороженности - тогда оно и так будет. Только с системде, гипотетически, у вендоров будет меньше причин костылять свою систему инициализации на С, что-бы не использовать бизибокс.

Так я признаю некоторые инженерные принципы юниксвея или не признаю некоторые инженерные принципы юниксвея?

Казнить нельзя помиловать. Ты признаешь наличие некоторых инженерных принципов. Но не признаешь набор инжденерных принципов юниксвея.

Ну, мы знаем, что посетителей храмов думают о глупцах атеистах :]

Угу, как я и написал - юниксвей, то есть целую кучу важных инженерных принципов, ты не признаешь :D

Вообще, у тебя кажется какая-то фобия по поводу того, что твои собеседники не признают некие ФУНДАМЕНТАЛЬНЫЕ заповеди.

Не понял твоей позиции - так они признают или не признают. То что у меня параноя, не значит что никто не хочет меня убить(C) :D

С чего ты это вообще взял - совершенно не ясно.

С ответов на аргумент «вот тут этот важный инженерный принцип не воплощен» я это решил. Ответов «да, это так, но вот есть достоинства а б и в, которые перевешивают» я не видел. Видел ответы «не нужен», «устарел», «принцип надо пересмотреть», «потернг сказал что ты врешь а я слишком туп что бы проверить»

But perhaps the most enduring objections to Unix are consequences of a feature of its philosophy first made explicit by the designers of the X windowing system....

Ты уверен, что подумал?

То что X не сильно юниксвейные - это бы известный исторически контраргумент против них.
И как кстати написано в твоей цитате они воплотили *один* из принципов юниксвея. Что позволило очень долго продержатся, но дело закончилось вот ситуацией сейчас, когда остальные принципы догнали.

Но не признаешь набор инжденерных принципов юниксвея.

Я не признаю некоторые примеры и утверждения Реймонда. Эта подветка началась с того, что кто-то рекомендовал читать AoUP, а я рекомендовал не воспринимать написанное там как писание. Вот и все.

Не понял твоей позиции - так они признают или не признают. То что у меня параноя, не значит что никто не хочет меня убить(C) :D

В отличие от тебя, я за твоих собеседников не решаю (%

То что X не сильно юниксвейные - это бы известный исторически контраргумент против них. И как кстати написано в твоей цитате они воплотили *один* из принципов юниксвея. Что позволило очень долго продержатся, но дело закончилось вот ситуацией сейчас, когда остальные принципы догнали.

Как минимум эта цитата про тот принцип, который ты усердно рекомендуешь воплотить в системде )) Посмотрим, что будет более юниксвейное, и будет ли

Кстате помнишь мы с тобой обсуждали мысли по поводу того какой должна быть замена systemd? Когда я указывал что нужна в той или иной форме системная шина на которую будут завязана группа системных демонов. И проблема собственно в том что бы сделать дизайн семантики взаимодействий и вообще дизайн этой части системы в целом? А что системд это таран который сформирует новый дизайн? :D

Ну вот. Я же говорил (см аттаченую цитату). Фактически убунту берет шину системд и садится на нее. Делая шину не внутренне лично поттеринговой - а общей системной шиной, на которой начинает существовать взаимодействие не только systemd демонов. Написанных несвязанными друг с другом коллективов разработчиков с разными целями. При чем делает это из соображений nih синдрома и личного жлобства :D Как бы если все закончится удачно, мы(сообщество) получим из этих ужасов очень полезный результат :D

В результате семантика взаимодействия на этой шине мутитрует от централизованно контролируемой к эволюционно базарно разрабатываемой.

А когда она выработается - можно будет написать малюсенький systemd-II который будет взаимодействовать не через хтонические дбасы, в котором все можно будет подменить скриптами, и который будет отличатся от init только реально полезным новым функционалом. Ну и наконец выкинуть все эти поделия в урну, вместе с апстартом :D

PS
Да, судя по мессаге у талантливого школьника знатный бугурт. Он внезапно почувствовал то же самое, что другие люди от его собственных действий. Ниче Леня, Марк ужо тебе бугурта то обратно доставит, отольется тебе твое поведение, хехехе :D PPS Что характерно, леня похоже реально не понимает зачем это все.

----

https://plus.google.com/115547683951727699051/posts/jgT3DuQf63a

Then, logind will auto-spawn getty services on the VTs, via systemd bus commands. It does shutdown/reboot with systemd services, and much more. Wanting to support that without actually running systemd, that's not going to be fun... It basically means you need to set up a systemd-like environment in quite some detail, without actually setting up systemd itself.

This excercise of under all circumstances avoiding systemd as PID 1 while still wanting to adopt much of its other components, that sounds like masochism — masochism centred at the spot where politics conflict with technical requirements...

Делая шину не внутренне лично поттеринговой - а общей системной шиной, на которой начинает существовать взаимодействие не только systemd демонов. Написанных несвязанными друг с другом коллективов разработчиков с разными целями.

Что по твоему является шиной? Каковые её свойства?

Я не питаю больших надежд на то, что делается из соображений nih синдрома и личного жлобства. eudev показал, что на этом далеко не уедешь.

семантика взаимодействия на этой шине мутитрует от централизованно контролируемой к эволюционно базарно разрабатываемой.

Есть у меня странное подозрение, что семантику контролирует поцеринг.

можно будет написать малюсенький systemd-II который будет взаимодействовать не через хтонические дбасы

Думаю, что DBus с нами навсегда.

у талантливого школьника

После повторного взгляда на код systemd я что-то не уверен в его талантливости.

Есть у меня странное подозрение, что семантику контролирует поцеринг.

«opensource is not about control»(C) :D То есть либо потеринг поймет что значит произнесенная им фраза - либо его аккуратно пошлют лесом.

Думаю, что DBus с нами навсегда.

На уровне взаимодействия с десктопом - да. В других местах - не уверен.

Думаю, что DBus с нами навсегда.

На уровне взаимодействия с десктопом - да. В других местах - не уверен.

Ну, в этой робкой попытке распила systemd на DBus не покушаются.

Ну, в этой робкой попытке распила systemd на DBus не покушаются.

Потому что нельзя все задачи решать одновременно - а работать надо прямо сейчас. Приемлемой семантики для системной шины - нет. Это типо факт. Гениальные архитектуры рождаются годами - тиот же юникс прилили до того что хотя бы *отдаленно* похоже на то что сейчас - пять лет минимум, а то и больше.

нанять реально большую команду программистов которая сможет делать некий софт(планирующийся для монополии), покрупнее (ну или как systemd) и с новыми фичами на которые все завяжутся.

Так как процесс принятия решения в дистрибутивах «меритократия» - то все дистрибутивы выкинут «свои поделия» и будут использовать именно этот монопольный софт.

О, нечасто сюда доходят. Но это еще не конец. Что стоит между выпустит и завяжутся, да еще с учетом меритократии? Звучит будто мэйнтейнеры действительно школьники класса 8го, которым покажи запуск системы на 5с быстрее и всё, дело в шляпе. Бородатый вон постоянно повторяет всякие прогнозы о том, что может произойти, если завязаться на <нехорошую вещь>, а тут все так взяли и прыгнули? Где хотя бы средняя техническая компетенция (высокая для прикопаться к новичку и послать его подрасти годика на 2-3, а потом ввести как опцию — не обязательна)?

а тут все так взяли и прыгнули?

Прыгнул редхат и потащил всех за собой в это болото. Очевидно, остальные игроки способны исключительно собирать пакеты по образцу федорки.

Это Столлман

Дай ка мне последний его коммит в хурд, и желательно с датой.

Не UNIX-way

Ты так говоришь, будто UNIX-way это всегда хорошо.

Вариант, но чересчур толстый. Еще мнения о том, как мы дошли до жизни такой?

tonko

Осторожнее, мы сейчас напишем системде! Похоже, в действительности, ваша вера в юниксвей не слишком сильна

нет чувак, это у тебя недостаточное зрение, чтобы отличить systemd от maked

а maked как раз был бы очень интересным вариантом, на котором можно было бы строить систему инициализации, юзерских сессий и возможно даже части работы по инициализации устройств

Вопрос в необходимости и эффективности. По большому счету все компоненты в стиле юникс вея уже доступны в кореутилс и подобном, пользователю остается написать политику. Только вот никто этого делать не хочет, почему то (%