Леннарт Поттеринг (Lennart Poettering) представил (http://lists.freedesktop.org/archives/systemd-devel/2012-Nov...) релиз системного менеджера systemd 196 (http://www.freedesktop.org/software/systemd/), сочетающего в себе функции системы инициализации, механизм для контроля за выполнением фоновых процессов, службу для журналирования событий и средства для управления сервисами, сеансами пользователей и подключаемыми устройствами. Systemd нацелен на интенсивную параллелизацию выполнения сервисов на этапе загрузки системы, вобрав в себя лучшие черты таких систем, как launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora), и избавившись от оформления сценариев запуска в виде shell-скриптов. В настоящее время на использование systemd уже перешли такие дистрибутивы, как Fedora, openSUSE, Mandriva и Arch Linux.
Из наиболее интересных новшеств можно отметить:- Поддержка каталога сообщений (http://www.opennet.ru/opennews/art.shtml?num=35352) ("Message Catalog (http://www.freedesktop.org/wiki/Software/systemd/catalog)"), структурированной базы данных для хранения детализированной информацию о сообщениях, записываемых в системный журнал. Каждая запись в каталоге состоит из набора полей, которые могут содержать данные, как в текстовом, так и в бинарном представлении. Данные могут связываться с информацией из внешних источников, например, могут приводится ссылки на документацию. Ключевые данные в каталоге индексируются для обеспечения оптимальной выборки;
- В udev добавлена поддержка загрузки дополнительных параметров устройств из индексированной БД "hwdb", манипулирующей данными в формате ключ/значение. В качестве ключа выступает идентификатор устройства в форме "vendor/product ID". В настоящее время в hwdb размещены данные из существующих баз идентификаторов PCI- и USB-устройств, а также дополнительные сведения, связанные с PNP, ACPI и OID. В будущем БД будет наполняться дополнительными данными, что в конечном итоге превратит её в централизованную БД для второстепенных метаданных, связанных с устройствами. Использование индексированной БД позволяет существенно повысить скорость выборки данных, в отличие от ранее используемых линейных списков параметров, требующих в процессе выборки полного перебора;- Обеспечена поддержка сборки udev и systemd без поддержки blkid и kmod, что может быть востребовано разработчиками встраиваемых систем, желающих свести к минимуму число используемых зависимостей;
- В Python-биндинги для подсистемы Journal добавлена поддержка стандартного фреймворка Python для ведения логов.
- Поддержка гибридного спящего режима ("hybrid sleep"), появившегося в ядре Linux 3.6 и комбинирующего спящий и ждущий режимы. Переход в ждущий режим осуществляется после предварительного сохранения образа памяти на диск. В ситуации когда запас аккумулятора иссяк, новый режим позволяет восстановить работу через загрузку с диска дампа памяти, как при спящем режиме. Если запас энергии не исчерпан, восстановление будет совершено почти мгновенно, как при ждущем режиме. Для использования нового режима следует использовать команду "systemctl hybrid-sleep";
- По умолчанию обеспечено монтирование файловых систем, содержащих компоненты для загрузки через EFI;
- В socket-юниты добавлена поддержка привязки к задачам и блокам данных меток системы мандатного контроля доступа SMACK;
- Прекращена поддержка различный устаревших и специфичных для определённых дистрибутивов концепций, таких как insserv, /etc/rc.conf (ArchLinux) и загружаемые на начальной стадии загрузки сервисы SysV (например, нестандартные уровни запуска 'b' и 'S');
- Journal API расширен новыми функциями для проверки наличия в используемой для хранения журнала ФС средств для уведомления об изменениях файлов. Если таких средств нет, то будет использоваться периодическая проверка изменения файлов через определённые промежутки времени;
- Многие из компонентов systemd теперь пропускают проверки на наличие прав root через PolicyKit, если PolicyKit не найден в системе. Указанное изменение решает многие проблемы, возникающие при использовании systemd на системах без PolicyKit;
- Команда "systemctl switch-root" теперь может осуществлять переключение на корневую ФС более одного раза, что может быть использовано для реализации схем offline-обновлений систем через предварительное применение обновления для синхронизированного второго корневого раздела с последующим перемонтированием разделов;- Стало возможным указание нулевого значения в поле с временем жизни временного фала ("age"), что указывает на необходимость удаления подпадающих по маску файлов при каждой чистке директорий;
- В утилиту coredumpctl добавлена команда "gdb" для вызова отладчика gdb с целью инспектирования выбранного дампа;
- В утилиту journalctl добавлена опция "--full" для вывода длинных сообщений в неизменном виде.
URL: http://lists.freedesktop.org/archives/systemd-devel/2012-Nov...
Новость: http://www.opennet.ru/opennews/art.shtml?num=35402
> ... лучшие черты таких систем, как launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, *Fedora*) ... на использование systemd уже перешли такие дистрибутивы, как *Fedora*, openSUSE ...Я что-то не понял, как так?
Fedora вначале перешла на Upstart, а затем на systemd.
> , и избавившись от оформления сценариев запуска в виде shell-скриптов. В настоящее время на использование systemd уже перешли такие дистрибутивы, как Fedora, openSUSE, Mandriva и Arch Linux.Как будто это что-то хорошее. Раньше разобраться мог средний админ, а сейчас не каждый программист это может сделать.
Какой красивый пример баттхерта перед неизведанным. Сам-то пробовал этот systemd?
сначала просьба показать его в SUS v3/v4, или хотя бы в LSB - а потом вопрос рассмотрим вопрос о пробывать.
>> А в нашей Вселенной sysvinit идет под лицензией GPLv2+
> Что сказать-то хотел?То, что странно что от вас sysvinit скрывает какие-то технологии с такой лицензией...
>> Бедный... Почитай man init, а? Весь sysvinit это *две* программы:
> Да? Ну-ка прочитай мне этим init'ом параметры загрузки какого-нибудь демона. Ор ГТФО.А почему это задачи инита?
> ДООО. Пока тысяча конфигов этого режима распарсится grep'ами, да выстроится нужная последовательность
> загрузки, пройдет куча времени.Пара секунд, на старом ноутбуке с убитым в хлам жестким диском. И?
На какой помойке-то вы хоть "тысячу конфигов" у uswsusp набрали?
Плюсую. Использую sysvinit. Ноут грузится за 7 секунд. Быстрее не нужно.
Минусую. Тебе не нужно, мне - нужно.
Зачем?
Затем, что каким-нибудь WM сыт не будешь. Уменьшат еще время загрузки - смогу загрузить что-то потяжелее и юзабельнее (для меня) за те же 7 секунд.
> Плюсую. Использую sysvinit. Ноут грузится за 7 секунд. Быстрее не нужно.А еще 640 килобайтов хватит всем :)
> Моментальную загрузку никаким SystemD не обеспечишь.Ну лично у меня система взлетает за ~5 секунд, ибо SSD. Это правда апстарт, но сути дела не меняет.
> Более того, "моментально" - это означает и то, что все нужные программы
> должны быть открытыми => только спящий режим.Ну вон там про гибридный режим написано. Хорошо придумано, имхо. Потому как "только спящий" режим на нотике приводит к тому что оперативка выжирает батарею и потом - вуаля - некорректное завершение системы. А тут быстрое рекавери если возможно и "уж как вышло" если с подзарядкой вовремя все-таки продолбался. Лучше чем резкий и некорректный шатдаун ОС.
> Ну лично у меня система взлетает за ~5 секунд, ибо SSD. Это
> правда апстарт, но сути дела не меняет.MBA взлетает из "спящего режима" за секунду. А главное, у него все программы уже запущены. И несмотря на неудобство интерфейса MacOSX, по сравнению с мозаичными WM, работать можно начать быстрее.
При этом скорость запуска OS на этом MBA + загрузка программ (перебежки по меню и т.д.) занимает действительно продолжительное время. Однако это крайне редко, вроде раза в неделю, когда обновления придут.
> Ну вон там про гибридный режим написано. Хорошо придумано, имхо.
Это гибернация, а не запуск системы с 0-я.
> MBA взлетает из "спящего режима" за секунду. А главное, у него все программы уже запущены.У меня ноут тоже взлетает за ~секунду. В лине. И программы уже открыты. Вот только оперативка в которой это самое состояние сохранено в виде котором за секунду просыпается кушает батарейку, итить. И если полной батареи хватает на ~неделю, то если делать шатдаун с почти пустой батареей - можно и пообломаться, когда батарейка сядет окончательно и все это счастье из оперативы вылетит в трубу.
> Однако это крайне редко, вроде раза в неделю, когда обновления придут.
Я не отрицаю что полный ребут и на нотике и на десктопе делается не часто, но это совсем не значит что мне хочется лишний раз ждать.
> Это гибернация, а не запуск системы с 0-я.
Это гибрид suspend to ram и suspend to disk. Очень здраво: если повезло то просыпаемся за секунду. А если не повезло - ну уж как получится, зато со всеми программами, без внеплановых потерь данных.
> можно и пообломаться, когда батарейка сядет окончательноА вот тут хотелось бы конечно, чтобы ноутбук при определенном заряде батареи переходил из ждущего режима в спящий (гибернация). Слыхал есть такое на венде, а вот как ни линуксах с этим не знаю.
> а вот как ни линуксах с этим не знаю.Ну вот граждане из systemd сделали поддержку гибридного режима, когда состояние и на диск льется и в RAM остается. Если сабжевую новость почитать.
> А вот тут хотелось бы конечно, чтобы ноутбук при определенном заряде батареи
> переходил из ждущего режима в спящий (гибернация). Слыхал есть такое на
> венде, а вот как ни линуксах с этим не знаю.Оно и без systemd, с этим, нормально в Линупсах.
Например:
http://goodies.xfce.org/projects/panel-plugins/xfce4-battery...
http://goodies.xfce.org/projects/applications/xfce4-power-ma...$ man pm-action
$ man sudoers
$ man sudo$ rpm -ql pm-utils|grep bin/
т.е. ты и тебе подобные не способны зайти на systemd home page и почитать описание и список тех самых проблем, которые решает systemd, найти рациональное зерно в доводах сторонников в предыдущих постах systemd-срачей, не читаешь даже новость, под которой спешь написать "очень важный" комментарий, при этом ты требуешь в двух словах ответить по-пацански на вопрос, ответ на который на самом деле тебя и таких как ты не интересует, при этом ты высераешь два абзаца бессмысленной х..иты вроде вот этого:>Не "новое". Просто в винде народец любит обновляться, не понимая, что это принесёт - "о, >новая версия, фишки обещают красивые" - побежал... А потом оказывается, что в новой версии >всё первернули вверх дном, жрать она стала больше, а задачи того, кто ставил, решать лучше >не стала.
>Быстрая загрузка - одна из таких фишек. Пузомерка в чистом виде. Ну какая разница, будет >система грузиться 5 или 8 секунд? Во-первых, этап до загрузки операционки обычно много >больше занимает. Во-вторых - если нужно быстро и чатсо включать/выключать машину то вам >режим сна нужен, а здесь любой init не при делах.нет уж, дудки. вести осмысленный диалог с вами, systemd-хейтеры, бессмысленно.
> нет уж, дудки. вести осмысленный диалог с вами, systemd-хейтеры, бессмысленно.Ёб...й в рот, пиши аргументы за systemd!
Почему я должен покупать вашу сранную розовую фиррари, если на своём джипе я обогнул Землю 40 раз,
дизель продаётся даже на Колыме, в Тибете и Ботсване, а ваш EURO-5 95 хрен наёдешь на планете.
Почему я должен покупать набор ключей TORX, когда у меня есть все под 6-гранники, и где его купить в колхозе.
Где гарантия того, что завтра не перестанут выпускать детали, а вернутся обратно к выпуску внедорожников?
Нахера мне в пустыне или в горах, парктроник, авс, хромированные диски и разгод до 100 за 4 сек.?
То что было до systemd не дизель, а самодельные снегоступы, кто их изолентой обматывал, кто тонкой веревкой, кто рыболовной леской. В каждой деревне свои мастера были.Успокойся, через год после выхода основных дистрибутивов ваши стенания будут вообще никому не интерсны.
Потратил годы жизни на получение супертайного знания и опыта кромсания сраных аналогов .bat файлов? Думал, вот оно, пошла карта, родился ультраспециалист, бабло лопатой будешь грести, обладая умением восстановления Linux систем после того как предыдущий мегаодмин там пару строк поправил год назад и забыл, а при обновлении весь парк корпоративных серверов накрылся? Нуну, рыдай теперь, Поттеринг пришел и сдал вашу уютненькую контору по изготовлению денег из ничего. Теперь любой школоадмин сможет за пол часа разгрести ситуацию с помощью удобного продуманного systemd.
> Теперь любой школоадмин сможет за пол часа огрести ситуацию с помощью удобного
> продуманного systemd.FIXED ;D
Хорош этот инструмент, или нет - покажет использование в бою.
Было 100500 случаев, когда сервис не стартовал по непонятной причине.
Или "стартовал", но процесса не было.
В этих случаях спасало банальное sh -x /etc/init.d/<service> start и копание.
Посмотрим, чем будет полезен systemd в нестандартных ситуациях.
>В этих случаях спасало банальное sh -x /etc/init.d/<service> start и копание.В этом то и дело, запаришься копаться ты в моих добавках, я то в своих разберусь как нибудь, но заменить меня будет чревато. Подумай с точки зрения работадателя а не исполнителя.
>>В этих случаях спасало банальное sh -x /etc/init.d/<service> start и копание.
> В этом то и дело, запаришься копаться ты в моих добавкахА можно конкретный пример ваших "добавок"?
> Подумай с точки зрения работадателя а не исполнителя.С точки зрения работодателя - заставлять админов документировать свои действия, особенно "нестандартные" (хотя путевые админы и так это делают) и гнать в шею тех, кто отказывается. Навязывать использование VCS. И без разницы какая система инициализации используется - если есть контроль версий и нормальные описания что сделано, как сделано и, главное, зачем сделано, то и работодатель может не париться как там чего загружается с точки зрения поддержки/сопровождения. Чтобы проверить качество и полноту документации время от времени проводить "учения" не только по восстановлению бэкапов, но и по настройке новых компов/серверов по документации (в идеале - не теми людьми, которые ее писали).
Это твои фантазии. А на практике надо все "вчера" и чтобы работало, назависимо от прихоти Благородного Святейшиства Админа. У тебя есть домашний высокооплачиваемый админ по бэкапу и восстановлениюю суповой ложки? С учениями, документацией, и прочим? Компы это давно ложки, ящики с цветными картинками. И systemd будет работать как часы. В отличии от миллиарда огрызков самописных скриптов.
В вашем мухосранске не слышали про процесс управления изменениями?
Системд пытаются натянуть на ентерпайз, где всё по уму и "науке". А в результате слышим про криворуких админов которые работать нормально не хотят. Это не аргумент, это какой-то позор.
> Системд пытаются натянуть на ентерпайз, где всё по уму и "науке"Вся проблема в том, что это то, как-раз и не нужно делать. Было бы очень здорово, если бы это "по уму и науке" идеально работало во всех случаях. Но, ни одна программа до сих пор этого не делает. И если мы имеем 20 программ, которые можно комбинировать, изолировать при необходимости одну от другой, и дебажить, то подобные локальные неполадки легко диагностировать исправить (той же "изолентой"-shellом). Не говоря уже о нестандартных локальных решениях, когда нужно "с перламутровыми пуговицами". Но, если у вас ентерпрайзный комбайн, который отвечает за "все вместе и еще чуть-чуть", то отладка, не стандартные конфигурации и исправление проблемм "на коленке за 10 минут" уже будут из разряда научной фантастики. Возможно, для ентерпрайза с платной поддержкой это не так и плохо, но для локального сисадмина становится сущим адЪом.
Там скомканный ответ. Если для ентерпрайза нужно системд то нужно делать всё по уму. Следовательно надо делать процесс управления изменениями. А если у нас уже отлажен этот процесс - рассказы про криворуких админов и кривой инит идут лесом.
Да и вообще скрипты по запуску всякого уже интегрированы в дистр. Портянки писать смысла нет.
> И если мы имеем 20 программ, которые можно комбинировать,
> изолировать при необходимости одну от другой, и дебажить,
> то подобные локальные неполадки легко диагностировать
> исправить (той же "изолентой"-shellом).Весь прикол и ирония судьбы в том, что на локалхостах абсолютно та же ситуация.
Если пользователь, именно пользователь, а не "тракторист".
> И systemd будет работать как часы.O'rly? :)
Вот на то и нужно время, чтобы systemd опробовали в продакшене и некоторые сняди розовые очки.
> Компы это давно ложки, ящики с цветными картинками.Неужели?
Они действительно 'ящики с цветными картинками' до тех пор, пока админ цветных картинок имеет возможность позвать кого-нибудь на приди посмотри.> У тебя есть домашний высокооплачиваемый админ
> по бэкапу и восстановлению суповой ложки?И первым делом, прежде чем елозить мышом по столу, этот домашний админ вот это
http://segfault.kiev.ua/smart-questions-ru.html
уже конечно прочитал и умеет применять?
Всё это умеет делать нормальный пользователь (не админ!) локалхоста.
Просто критерии нормального, в Линукс, за последние лет пять, почему-то(?) сильно сместились.> И systemd будет работать
на планшетах, мобильных и карманных тачевых устройствах предназначенных для юзания медиаконтента в сегменте рынка который пытаются сделать массовым.
Неужели не видно, что эти сильно нишевые технологии пытаются лоббировать и натянуть не только на десктопные системы, но даже на сервера?> как часы
Багфиксы влетали в софт и 30 лет назад и будут влетать через 50.
Идеальный комбайн, который не требует отладки, не требует ремонта в случае поломки и всегда работает, это иллюзия.
С инитом в полевых условиях много проще.
>>В этих случаях спасало банальное sh -x /etc/init.d/<service> start и копание.
> В этом то и дело, запаришься копаться ты в моих добавкахНе бойтесь, c 2003 года копаемся)
"sh -x" помогает в 99% случаев.> Подумай с точки зрения работадателя а не исполнителя.
Работодатели предпочитают не брать исполнителей, которые пишут необоснованно запутанные "добавки".
Успокойтесь, расслабтесь и откиньтесь на спинку кресла. За вами уже выехали.
> Теперь любой школоадмин сможет за пол часа разгрести ситуацию с помощью удобного
> продуманного systemd.Вам сюда: #90
Ждем показательных результатов "разгребания".
> т.е. ты и тебе подобные не способны зайти на systemd home page и почитать описание и список тех самых проблем, которые решает systemd,после этого открыть список проблем в systemd и сильно подумать - как программу с таким количеством критических проблем в трекере допустили к использованию в критическом месте - которым является загрузка.
> в критическом месте - которым является загрузка.Так на то и федористы чтобы на них тестировать.
>> в критическом месте - которым является загрузка.
> Так на то и федористы чтобы на них тестировать.Федорист твой папа, а разработчики дистрибутива Fedora Linux это люди, решающие важные задачи.
> Федорист твой папа, а разработчики дистрибутива Fedora Linux это люди, решающие важные задачи.Так я про пользователей федоры. Есть те кто делает самолеты. А есть летчики-испытатели. Это как правило разные люди.
> а разработчики дистрибутива Fedora Linux это люди, решающие важные
> задачирешив при этом важную задачу в создании в системе файлопомойки.
А чтобы этот забор не развалился, его подпёрли бревном из симлинков,
чем окончательно сломали в своей системе возможность держать системные каталоги
на разных устройствах.
Если заметать мусор под диван, чище в комнате от этого не станет.
Скорость выполнения дисковых операций можно решать не только распараллеливанием,
наращиванием кеша и оборотов шпинделя.
Ну сидя на старом, устранения дыр и различных багов (которые есть всегда) ждать не приходится.
Также я бы не сказал, что какой-то софт в линуксе меня устраивает на 100%. Везде компромисы, все время ждешь, что вот тут пофиксят и больше ничего не изломают.
А на системд переходят разработчики. Всяким ламерам, которые не могут поддерживать систему самостоятельно следует с этим смириться и перестать ныть. С сабжем работать можно, надо чуть разобраться.
>на системд переходят разработчикиОтличный способ заниматься ерундой вместо разработки, чтобы при этом со стороны казалось, что ты занят работой.
>>на системд переходят разработчики
> Отличный способ заниматься ерундой вместо разработки, чтобы при этом со стороны казалось,
> что ты занят работой.Это вообще что за бред? Кто разрабатывает а кто в тырнетах трендит?
> Не "новое". Просто в винде народец любит обновляться, не понимая, что это
> принесёт - "о, новая версия, фишки обещают красивые" - побежал... А
> потом оказывается, что в новой версии всё первернули вверх дном, жрать
> она стала больше, а задачи того, кто ставил, решать лучше не
> стала.
> Быстрая загрузка - одна из таких фишек. Пузомерка в чистом виде. Ну
> какая разница, будет система грузиться 5 или 8 секунд? Во-первых, этап
> до загрузки операционки обычно много больше занимает. Во-вторых - если нужно
> быстро и чатсо включать/выключать машину то вам режим сна нужен, а
> здесь любой init не при делах.у тебя нет ноутбука с уефи.
Аргументируйте, пожалуйста, причем тут uefi?
При том, что этап загрузки до старта ОС несколько быстрее при использовании UEFI.
> В восьмерке вот загрузку за 5 секунд сделали, с инит-скриптами этого не добиться, с systemd еще возможно в будущем.Дывись, можно - попробуйте Debian. Никогда не говори никогда.
Только что взглянул - qemu-образ загрузился за ~2-3сек (с апачем и еще небольшой кучкой сопутствующих ему сервисов).
> Дывись, можно - попробуйте Debian. Никогда не говори никогда.У меня убунта даже с нуля на SSD за 5 секунд грузится. Bios дольше затупляет...
>> Дывись, можно - попробуйте Debian. Никогда не говори никогда.
> У меня убунта даже с нуля на SSD за 5 секунд грузится.
> Bios дольше затупляет...Речь шла о "инит-скриптах". Вы открутили сперва в убунту апстарт или просто не умеющий читать дебил?
PS: Биос и задержку в grub я даже не брал в расчет. Естественно, это будет куда больше чем 2-3сек.
> Речь шла о "инит-скриптах". Вы открутили сперва в убунту апстарт или
> просто не умеющий читать дебил?А, понял. Вы у нас пиндец умный перец:
1) Вы прекэшанули все в оперативке, так что бутовый процесс был полным cache hit :)
2) Вы бутанули все на виртуалке где полторы железяки и минимальная конфигурация.Проблема у гражданина гения только в одном: при загрузке на реальном железе кэш холодный и все будет намного хуже. И намного больше оборудования, программ и прочая в общем случае.
Как бы кроме "инит скриптов" есть еще "объем работы" и "условия в которых работа происходит", если вдруг такой гений этого не понял.
Поэтому ваш тест сферического коня в виртуалочке - выеденного яйца не стоит. Ибо на загрузку на реальном железе с холодным кэшом не похоже ни разу.
> 1) Вы прекэшанули все в оперативке, так что бутовый процесс был полным
> cache hit :)
> 2) Вы бутанули все на виртуалке где полторы железяки и минимальная конфигурация.С точностью до наоборот. Толку от cache hit в процессе загрузки - 0. Предлагаю осилить эту простую истину самостоятельно. Или вы попусту не знаете как работает кэш?
Железок заметно больше полторы, несколько дисков...
> при загрузке на реальном железе
> кэш холодный и все будет намного хуже.При загрузке "на реальном железе" - блоковый кэш работает абсолютно также. До старта виртуалки он точно также пуст, как и на реальном железе. Не говоря уже о том, что там не эмулируется CPU и оборудование.
> Поэтому ваш тест сферического коня в виртуалочке
Вы представляете, что кто-то будет персонально для вас проводить измерения на реальном железе или смотреть логи?
Ок. Вот небольшой бекапный сервер (NFS, 4x2Tb диска) - 3 сек после POST.
> С точностью до наоборот. Толку от cache hit в процессе загрузки - 0.Только не при старте виртуалки. Там есть вполне ощутимая разница - на холодную оно стартует или на горячую. Бенчи в виртуалках имеют свойство бенчмаркать что угодно кроме собственно процесса загрузки который был бы на холодную в железяке.
> Предлагаю осилить эту простую истину самостоятельно. Или вы попусту не знаете как работает кэш?
Я попросту в курсе того что загрузка виртуалки - совсем иной процесс нежели загрузка железячной машины на холодную. Вот чего-чего, а с виртуалками я имел дела много. И физику/логику процесса я вполне себе представляю. Она может сильно отличаться от того что будет наблюдаться при загрузке реальной железяки. Специально сравнивал - виртуалка реально может взлететь за единицы секунд если кэш удачный. На реальном оборудовании та же копия оси обычно ведет себя куда скромнее.
> Железок заметно больше полторы, несколько дисков...
И чего?
>> при загрузке на реальном железе кэш холодный и все будет намного хуже.
> При загрузке "на реальном железе" - блоковый кэш работает абсолютно также.При юзеже виртуалок есть некислая вероятность что дисковый кэш хоста грамотно подкеширует потребные куски диска виртуалки и время I/O в некоторых местах окажется близким к нулю. Особенно если с этим диском хоть что-то делали раньше.
> До старта виртуалки он точно также пуст, как и на реальном железе.
Мягко говоря, не факт. А еще виртуалки можно запускать с опциями ведущими к нарушению семантики синхронизации записи. Так они даже bare metal обгоняют. Правда радости то с этого.
> Не говоря уже о том, что там не эмулируется CPU и оборудование.
Вот что-что а процессор эмулируется очень неплохо. Даже при совсем софтварной эмуляции он редко будет узким местом, не говоря уж о акселерации KVM, где оно 90-95% скорости голого железа выжимает запросто.
> Вы представляете, что кто-то будет персонально для вас проводить измерения на реальном
> железе или смотреть логи?Не, конечно, намного лучше втирать какой-то ламерский буллшит на форуме.
> Ок. Вот небольшой бекапный сервер (NFS, 4x2Tb диска) - 3 сек
> после POST.Как насчет указания конфигурации и bootchart?
И вообще - я не допираю: что вы доказать то пытаетесь? Обычно сравнения классического инита с современными системами инициализации оказываются не в пользу оного. Если на одной и той же конфиге в одних и тех же условиях с одним и тем же набором сервисов. А то если пиписьками меряться - вон парни ARMовскую борду за 0.3 секунды забутявили. При вообще дохленьком проце. У них забористее. Правда вот у них конфига урезанная донельзя, но если уж охота показать красивую цифру... :)
Не трать силы, это секта ненавсисти к RedHat. До него и во 2 чтении не дошло, что такое кэш виртуальной машины. Точнее дошло давно, да прикидывается, чтобы хоть на излете да лягнуть еще разок.
> Бенчи в виртуалках имеют свойство бенчмаркать что угодно кроме собственно процесса загрузки который был бы на холодную в железяке.Тому есть более разумное объяснение. Неужели вам нужно объяснять почему?
> Вот чего-чего, а с виртуалками я имел дела много.
> Специально сравнивал - виртуалка реально может взлететь за единицы
> секунд если кэш удачный.Поясните что вы этим подразумеваете. Начальные условия: в кеше нет абсолютно ничего, файл с образом виртуалки лежит на диске. Жду описания "удачи".
>> Железок заметно больше полторы, несколько дисков...
> И чего?Я ответил вам, вот чего.
> При юзеже виртуалок есть некислая вероятность что дисковый кэш хоста грамотно подкеширует
> потребные куски диска виртуалки и время I/O в некоторых местах окажется близким к нулю.Гораздо вероятнее, что подобную ерунду при старте - "подкеширует" VFS в самой виртуалке. Как и на физическом сервере.
>> До старта виртуалки он точно также пуст, как и на реальном железе.
> Мягко говоря, не факт.Что, система от нечего делать *сама* читает файлы на диске и принудительно пытается запихать все это в кеш?
>> Не говоря уже о том, что там не эмулируется CPU и оборудование.
> Вот что-что а процессор эмулируется очень неплохо.Вы можете это "неплохо" в цифирки перевести? KVM мне не интересен по условиям задачи.
>> Ок. Вот небольшой бекапный сервер (NFS, 4x2Tb диска) - 3 сек
>> после POST.
> Как насчет указания конфигурации и bootchart?Вам показали и конфигурацию и время загрузки. bootchart будете дома себе разводить и однокласникам показывать.
> И вообще - я не допираю: что вы доказать то пытаетесь?
Я показал, что "барьер" в 5сек загрузки - совершенно никакой не предел для скриптов на sysvinit. Хорошие майнтейнеры, параллельный запуск сервисов - и вуаля.
> Обычно сравнения классического инита с современными системами инициализации
А что такое "классический init"? Сейчас, наверно, выяснится, что в Debian по вашему определению - "неклассический init"?
> Тому есть более разумное объяснение. Неужели вам нужно объяснять почему?Я уже сказал почему: риски попадания в горячие кеши (если у вас достаточно оперативы для старта виртуалки то и дисковый буфер у вас априори здоровый) + намного меньше действий по инициализации системы.
>> секунд если кэш удачный.
> Поясните что вы этим подразумеваете. Начальные условия: в кеше нет абсолютно ничего,Как это при cold boot обеспечивается - понятно. А как это на горячую обеспечивается?
> файл с образом виртуалки лежит на диске. Жду описания "удачи".
Да блин, случайно сунулись в этот файл полчаса назад или там когда еще и он подкэшировался. Дисковый буфер линя довольно хорошо удерживает информацию. Еще всякие префетчинги и прочая могут вмешаться. Как синхронная запись обрабатывается - тоже интересный вопрос - зависит от настроек и дефолтов виртуализатора.
В результате из-за суммы всех этих факторов + минимальной инициализации железа времянки процесса получаются как правило не особо похожи на bare metal.
Так что такой тест особую ценность из себя не представляет: до того как вы сможете запускать виртуалки, надлежит запустить железку. И на десктопах, планшетах, нотиках, телефонах, телевизорах и прочей мобильшине и (около)эмбеддовке это время очень даже может анноить.
>> И чего?
> Я ответил вам, вот чего.Ну да, замеряли какой-то бред. Кстати если что - 5 секунд которые я приводил как пример - это до момента когда у меня перед физиономией появляется десктоп и я им могу начать пользоваться. То-есть со взлетом полновесного гуйного окружения со всей требухой.
> Гораздо вероятнее, что подобную ерунду при старте - "подкеширует" VFS в самой
> виртуалке. Как и на физическом сервере.Пардон, для хоста работа с файлом виртуалки - тоже просто работа с файлом. И он тоже это с удоволььствием кэширует.
>> Мягко говоря, не факт.
> Что, система от нечего делать *сама* читает файлы на диске и принудительно
> пытается запихать все это в кеш?Скорее, в системе есть достаточно много процессов работающих с файлами + юзерь :). И кроме случая когда хост загружен вот прям сейчас и тут же пнута виртуалка - остальные ситуации как-то не гарантируют того что кэш холодный.
>> Вот что-что а процессор эмулируется очень неплохо.
> Вы можете это "неплохо" в цифирки перевести? KVM мне не интересен по условиям задачи.Для чистого quemu не заморачивался по очевидным причинам, для KVM - привел.
>> Как насчет указания конфигурации и bootchart?
> Вам показали и конфигурацию и время загрузки.Мне показали какой-то фокус в духе наперсточников, если называть вещи своими именами. И предложили поверить на слово.
1) Предложение прогнать тесты с заведомо холодным кэшом было отвергнуто.
2) Предложение предоставить бутчарт также было отвергнуто.Вот пусть кто хочет тот и верит таким "железобетонным" пруфам всяких балаболов на форуме. Но это буду не я, извините.
> bootchart будете дома себе разводить и однокласникам показывать.
Нормально. Как только я нормальные пруфы попросил (которые не очень просто подделывать) - так в кусты? Так и запишем.
>> И вообще - я не допираю: что вы доказать то пытаетесь?
> Я показал, что "барьер" в 5сек загрузки - совершенно никакой не предел для скриптов на sysvinit.Во первых, вы показали какие-то махинации с наперстками. Без внятных технических пруфов. Во вторых, вы судя по всему говорили о весьма лайт системе. Я говорил о взлете моего десктопа с кучей барахла, XFCE и прочая.
Простите, тот же фороникс и то бутчарты собрать в состоянии :)
> Хорошие майнтейнеры, параллельный запуск сервисов - и вуаля.Дешевый понт без пруфов.
>> Обычно сравнения классического инита с современными системами инициализации
> А что такое "классический init"? Сейчас, наверно, выяснится, что в Debian
> по вашему определению - "неклассический init"?А выясняется легко. Вот например пусть адаптер получает по DHCP айпишник пяток секунд. Остальное при этом как, покурит бамбук или отрабатывает? При условии что большинству сервисов конкретно вот эта вот сеть и сетевка для взлета не требуется. В том же апстарте это довольно просто разруливается: те кому надо сеть стартуют по событию "сеть взлететь" (в простейшем случае).А кому не надо - по более ранним. Очень просто запрограммить желаемое поведение считанными строками конфига.
> если у вас достаточно оперативы для старта виртуалки то и дисковый буфер у вас априори здоровыйТелепатический модуль закоротило? Итак, "оперативы" у меня достаточно (ибо виртуалка стартует). Что вы можете сказать про размер дискового буфера? "Здоровый" - это сколько в попугаях?
>> Поясните что вы этим подразумеваете. Начальные условия: в кеше нет абсолютно ничего,
> Как это при cold boot обеспечивается - понятно. А как это на
> горячую обеспечивается?Вы идиот?
>> файл с образом виртуалки лежит на диске. Жду описания "удачи".
> Да блин, случайно сунулись в этот файл полчаса назад или там когда
> еще и он подкэшировался.Вот и объясняю в 100й раз - "не сувались" (с). Как вам еще проще объяснить?
> В результате из-за суммы всех этих факторов...
Потек мыслею... Ликбез не нужен - ты зачет не сдал ;)
>> Гораздо вероятнее, что подобную ерунду при старте - "подкеширует" VFS в самой
>> виртуалке. Как и на физическом сервере.
> Пардон, для хоста работа с файлом виртуалки - тоже просто работа с
> файлом. И он тоже это с удоволььствием кэширует.Да, конечно. Но только после старта виртуалки. И не целиком, а блоками...
> Скорее, в системе есть достаточно много процессов работающих с файлами
Дубина, некому там работать с образом, который лежмя лежит и нафиг никому не нужен.
> Для чистого quemu не заморачивался по очевидным причинам, для KVM - привел.
Ну и на кой черт тут этот KVM? Вы можете без подсказки вспомнить что за система виртуализации использовалась?
> 1) Предложение прогнать тесты с заведомо холодным кэшом было отвергнуто.
С каким еще холодным кешем? Сервер был когда-то перезагружен. Кэш - холоднее некуда.
> 2) Предложение предоставить бутчарт также было отвергнуто.
Вам показывают - вот он загрузился от груба до логина за 3сек. Что вам еще?
>> bootchart будете дома себе разводить и однокласникам показывать.
> Нормально. Как только я нормальные пруфы попросил (которые не очень просто подделывать)Ага, Всемирный Заговор, блин. Все вам врут - идите отсюда, вы шапочку из фольги в палате забыли...
Во-первых, образы виртуальных машин кэшируются хостовской операционкой, во-вторых, устройств под ней, требующих определения и инициализации, в разы меньше, чем на реальной машине, а те что есть - очень простые и многие вещи неподдерживающие полноценно. Есть еще множество нюансов. Плюс вы не написали, запускалась ли у вас графическая система и какой-нибудь DE, сравнимый с тем, что в Windows, а не какой-нибудь простейший WM.
> Во-первых, образы виртуальных машин кэшируются хостовской операционкойЭто не отменяет того факта что будет очень хорошо, если их запуск на хосте возьмет на себя система инициализации. Так что при взлете хоста взлетят и виртуалки. В идеале еще и с каким-нибудь delayed start если их много, чтобы дисковую подсистему хоста раком не поставить.
а сейчас их запускает магия и эльфы, если они добавлены в тот-ж автозапуск у например виртменеджера?
> автозапуск у например виртменеджера?А сейчас надо какой-то виртменеджер и что там еще. У меня его вообще нет например. А виртуалки KVMные - есть. Ы?
> Во-первых, образы виртуальных машин кэшируются хостовской операционкойМожет у вас и кешируются. А у меня - память не настолько безграничная.
> во-вторых, устройств
> под ней, требующих определения и инициализации, в разы меньше, чем на
> реальной машине, а те что есть - очень простые и многие
> вещи неподдерживающие полноценно.Ага. В т.ч. CPU эмулируется, на тип виртуализации я не случайно обратил внимание.
> Плюс вы не написали,
> запускалась ли у вас графическая система и какой-нибудь DE, сравнимый с
> тем, что в Windows, а не какой-нибудь простейший WM.Я ясно написал что запускалось и для чего этот образ.
> Может у вас и кешируются. А у меня - память не настолько безграничная.Простите, отсюда не виден процент cache hit при чтении. И как уже сказано, в виртуалке вообще взлет системы по минимуму. На реальной железке да еще с кучей программ все обычно сильно разлапистее.
> Я ясно написал что запускалось и для чего этот образ.
Да, вы ясно написали что это сферический тест в вакууме. Не имеющий ничего общего с взлетом всей операционки на холодную на реальном оборудовании.
>> Может у вас и кешируются. А у меня - память не настолько безграничная.
> Простите, отсюда не виден процент cache hit при чтении.Файл с образом виртуалки лежмя лежал на диске до того, как ее запустили.
> И как уже сказано, в виртуалке вообще взлет системы по минимуму.
Расшифруйте.
> На реальной железке да еще с кучей программ все обычно сильно разлапистее.
Да, несколько шустрее. Учитывая, что у реального сервера и памяти больше, и процессор физический... В общем, разика в два шустрее может быть, как минимум. qemu - штука не быстрая...
> Файл с образом виртуалки лежмя лежал на диске до того, как ее запустили.Опять же - верить на слово нафиг надо. Вот когда ребут на холодную в реальном железе - там оно очевидно уже. Потому как кэш заведомо пустой на момент старта. А с виртуалками - там очень легко лопухнуться. Кэши штука такая. Легко набрать, а потом они довольно агрессивно держатся про запас.
> Расшифруйте.
Оборудования там минимум. Условия максимально тепличные. Инициализация оборудования занимает около ноля. Тогда как на современном компьютере с богатой периферией, кучей дисков которые надо смонтировать и прочая - все получается сильно менее радужно.
>> На реальной железке да еще с кучей программ все обычно сильно разлапистее.
> Да, несколько шустрее. Учитывая, что у реального сервера и памяти больше,
> и процессор физический... В общем, разика в два шустрее
> может быть, как минимум. qemu - штука не быстрая...В процессор довольно редко упирается. Если посмотреть бутчарты, в основном упирается в I/O (при замене на SSD наступает лютый epic win при прочих равных, что как бы намекает) и в классической схеме - ожидание того и сего там и тут, когда почти никакие компоненты системы не прогружены, система занимается "тупоwaiting-ом". В современных системах инициализации "тупоwaiting" почти отпадает, бутчарт получается довольно плотным.
Особо вумные, типа убунтов и вроде как федористов - юзают префетчинг (силами небольшого демона), прогревая кэш при загрузке до того как эти данные реально понадобятся, пока диск не озадачен. Что позволяет им таки получить иногда некий cache hit при загрузке и еще малость скостить время на I/O. Нужность подобных наворотов - штука интересная, но помнится в клинических случаях типа загрузки с медленных механических дисков разница за счет подобных ухищрений в сумме натикивала достаточно заметная.
>> Файл с образом виртуалки лежмя лежал на диске до того, как ее запустили.
> Опять же - верить на слово нафиг надо.Я себе верю. А вы, предполагается, должны верить мне - т.к. если вы не доверяете приводимой мной информации, то весь разговор о моих данных бессмысленный.
> А с виртуалками - там очень легко лопухнуться.
Ради б-га, но причем тут я? Вам вполне ясно описали исходные данные: к образу не было обращений до момента запуска.
> Оборудования там минимум. Условия максимально тепличные. Инициализация оборудования
> занимает около ноля. Тогда как на современном компьютере с богатой периферией,
> кучей дисков которые надо смонтировать и прочая - все получается сильно
> менее радужно.Вам показали как.
> В процессор довольно редко упирается.
Я теряю терпение. Причем здесь "упирается", когда речь идет о различиях при прочих равных? I/O лимитируется системой, в которой запускается виртуалка.
> Я себе верю. А вы, предполагается, должны верить мне - т.к.
> если вы не доверяете приводимой мной информации, то весь разговор о
> моих данных бессмысленный.А у меня нет оснований вам верить без внятных технических пруфов. Штуки типа бутчартов правдоподобно подделать геморройно и потому им доверия намного больше.
> Ради б-га, но причем тут я? Вам вполне ясно описали исходные
> данные: к образу не было обращений до момента запуска.Да, и достали с потолка какие-то 2 секунды. Ну я с потолка и секунду достану. А поди проверь что ее не было :)
> Вам показали как.
Мне показали какой-то наперсточный фокус без каких либо пруфов. Взяли из рукава 2 секунды и помахали ими. И все.
> при прочих равных? I/O лимитируется системой, в которой запускается виртуалка.
Логично. И чаще всего упирается в I/O а не процессор и больше всего ожидается завершение I/O если процессор достаточно мощный. Тем не менее, на разлапистой системе с кучей сервисов (это явно не про то что вы загрузили) оверхед на дерг шелл интерпретера может себя показать. А вы наверное бутанули какую-то совсем пустую виртуалку без нифига и полутора железками. Если продолжить ту же логику, LXC контейнер вообще от системы отпиливается за микросекунды наверное. Ну а чо, совсем выбросили фазу инициализации ядра и оборудования оным, инициализацию тоже можно выбросить :)
systemd - это из разряда "чинить то, что не поломано"
автомобили - это из разряда "чинить то, что не поломано" (ведь есть лошади)
Ок. Какие реальные проблемы решает systemd? Вот то, с чем вы столкнулись или ваши знакомые?
> Ок. Какие реальные проблемы решает systemd?- Простой мониторинг и рестарт фоновых сервисов.
- Упрощение и ускорение впихивания нового сервиса в систему в разы.
- Параллельный старт сделанный не через задний проход.
- и без дрюкания на каждый 20кб демон 800кб интерпретера с поводом и без, так что взлет интерпретера занимает больше чем старт сервиса.
- Запуск программ по более-менее продвинутым критериям (событиям).Как-то можно и без всего этого обойтись. Да, можно из москвы в питер и на клячах доехать. Правда зимой вы будете давать дубаря, летом - обливаться потом, а поездка займет чуть ли не неделю. А можно в "сапсане" за 3-4 часа просвистеть, после чего пиндеж о том что оно дескать электричество жрет и вообще требует уйму инфраструктуры кажется уже старческим ворчанием.
Спасибо.
Еще надо добавить унификацию. Зоопарк разных скриптов и систем инициации скоро вымрет.
Стоит 1 раз потерпеть и привыкнуть если в итоге будет уже какой-то стандарт в загрузке линуксов.
>> Ок. Какие реальные проблемы решает systemd?
> - Простой мониторинг и рестарт фоновых сервисов.Задача, если у exim в paniclog не пусто, чё он будет делать в в фоне?
> - Упрощение и ускорение впихивания нового сервиса в систему в разы.
На sysvinit это ваще не проблема.
# cp ~/myscript.sh /etc/init.d/
# chkconfig myscript.sh --level 235Так что, не аргумент.
> - Параллельный старт сделанный не через задний проход.
Это влияет только на время.
> - и без дрюкания на каждый 20кб демон 800кб интерпретера с поводом
> и без, так что взлет интерпретера занимает больше чем старт сервиса.Это влияет только на время.
> - Запуск программ по более-менее продвинутым критериям (событиям).Вы когда чистите зубы, во время самой чистки выключаете воду для экономии ресурсов?
> Как-то можно и без всего этого обойтись. Да, можно из москвы в
> питер и на клячах доехать. Правда зимой вы будете давать дубаря,
> летом - обливаться потом, а поездка займет чуть ли не неделю.
> А можно в "сапсане" за 3-4 часа просвистеть, после чего пиндеж
> о том что оно дескать электричество жрет и вообще требует уйму
> инфраструктуры кажется уже старческим ворчанием.Хуё...ые у вас аналогии, Сапсан как раз катает по наезжанной трассе.
А systemd - это реактивная авиация со своими аэродромами, которые
надо строить, обучать персонал и юзарем выдавать затычки в уши,
чтоб не глохли.
> На sysvinit это ваще не проблема.
> # cp ~/myscript.sh /etc/init.d/
> # chkconfig myscript.sh --level 235Пардон, а что мешает из подобных систем иницилизации в случаях когда надо шеллскрипт дергать? Какая-то особая религия? Просто таких случаев - полторы штуки на тысячу. Ну вот там пусть шеллскрипты и живут себе.
А зачем на взлет 20 кило демона с совершенно типовыми свойствами надо дергать 800 кило интерпретер и простыню текста на страницу я не понимаю. Мне написать 3-5 строк в конфиг проще и работает оно потом куда лучше.
> Так что, не аргумент.
Почему-то фаны доисторического инита всегда забывают что в случае если конфига реально не хватило для какой-то суперкастомщины то возможность пнуть шелскрипт никуда не делать.
Вот только я за...сь самолично костыли ставить при желании пнуть скажем некий сервис в LXC контейнере или корректно запустить KVM виртуалку например. Нехай системный запускач это умеет, раз уж это подсистемы ядра. Если напихали фич как у аэробуса - ну так и бортовой компьютер нормальный для управления должен быть. Вожжи или даже руль от автотаза как интерфейс управления такой штукой ну совершенно не катят.
>> - Параллельный старт сделанный не через задний проход.
> Это влияет только на время.А я не нанимался ждать компьютеры - нехай они меня ждут. Чем чаще это будет именно так - тем лучше.
>> и без, так что взлет интерпретера занимает больше чем старт сервиса.
> Это влияет только на время.См. выше.
>> - Запуск программ по более-менее продвинутым критериям (событиям).
> Вы когда чистите зубы, во время самой чистки выключаете воду для экономии ресурсов?Да, иногда выключаю. Ибо тупо сливать в канализацию чистую воду. Да и нанче от дебилов счетчики воды сделали - так что оно превращается в слив бабла в канализацию в прямом смысле слова. Вот в таком формате это даже последний имбецил понимает :)
>> о том что оно дескать электричество жрет и вообще требует уйму
>> инфраструктуры кажется уже старческим ворчанием.
> Хуё...ые у вас аналогии, Сапсан как раз катает по наезжанной трассе.
> А systemd - это реактивная авиация со своими аэродромами, которые
> надо строить, обучать персонал и юзарем выдавать затычки в уши, чтоб не глохли.Нормальная. Трассу знаешь ли строить надо было. Регулярно обслуживать и прочая. И за это норовят слупить прилично бабла. Ну, я не против - желающие могут трястись в бричке неделю по морозу/жаре. А я лучше РЖД денег дам. Хоть они и монополисты гадские, но время ямщиков безнадежно ушло. Лошади остались только в сильно некоторых, очень специальных применениях. И это правильно.
> при желании пнуть скажем некий сервис в LXC контейнере или корректно запустить KVM виртуалкуНу да. Только вот недавно в листах системд обобсуждались как правильно пускать lxc. Оказывается надо спецутили для этого. Просто чудесно.
И да. Я не вижу ответа на вопрос про мониторинг. Человек явно спросил по этому поводу. Расскажи как просто мониторить в почтовике размер очереди, место на диске, место в почтовом ящике и прочее из системд.
> спросил по этому поводу. Расскажи как просто мониторить в почтовике размер
> очереди, место на диске, место в почтовом ящике и прочее из системд.Ну вот для таких наворотов уже и можно пинать шеллскрипты с желаемой логикой или что вам там удобно. А каждой мелочевке прописывать полновесные портянки где жуткое месиво кода и конфигурации - очень не прикольно.
Дадада. И тут же возникает вопрос зачем нужен этот системд если всё обскриптовать. А если ещё побольше подумать то тут и скрипты не нужны. Нужен спецсофт.
> Дадада. И тут же возникает вопрос зачем нужен этот системд если всё обскриптовать.Что - все? Какой-то один конкретный exim под какие-то кастомные требования? Нехай обскриптовывается, на то и хитрозагнутая хотелка чтоб кастомную логику скриптом сделать.
А вот совершенно шаблонный запуск виртуалок, контейнеров, типовых сервисов и прочая - нафиг надо скриптовать. Все хорошо в меру. В том числе и скриптинг. А то так можно дойти и до переписывания xorg как кучки скриптов.
> Что - все? Какой-то один конкретный exim под какие-то кастомные требования? Нехай обскриптовывается, на то и хитрозагнутая хотелка чтоб кастомную логику скриптом сделать.Мониторинг обскриптовать. Зачем это надо если всё более менее сложное ключами системд не сделаешь. А если всё равно будут портянки скриптов, какое же тут улучшение от системд?
> Нехай обскриптовывается, на то и хитрозагнутая хотелка чтоб кастомную логику скриптом сделать.
На то есть система мониторинга. А скриптам и прочем бирюлькам из системд тут вообще делать нечего.
> А вот совершенно шаблонный запуск виртуалок, контейнеров, типовых сервисов и прочая - нафиг надо скриптовать.
Про lxc выше уже говорили. Расскажи как улучшится запуск всего остального по сравнению с обычным инитом. Ничего такого особенно улучшеного не вижу.
> Да и нанче от дебилов счетчики воды сделали - так что оно превращается в слив бабла в канализацию в прямом смысле слова. Вот в таком формате это даже последний имбецил понимаетВот так вас недебилов и разводят. Поставили новую разрекламированную мульку и думают что всех накололи.
> Вот так вас недебилов и разводят. Поставили новую разрекламированную мульку и думают что всех накололи.По крайней мере, срач в канализацию чистой водой сокращается. Ибо лупит по кошельку. Понятное дело что капиталисты заботились о кошельке. А заодно и об экологии. Ну, так получилось. Это конечно побочное действие. Но - фича, фича! Встроенный антидебильник :)
>срач в канализацию чистой водой сокращается. Ибо лупит по кошелькугонево. счетчики я поставил только чтобы меньше платить, воду лью точно так же, как и когда платил по нормативу, а вот оплата меньше в 4-5 раз получается.
> счетчики я поставил только чтобы меньше платить, воду лью точно так же,Ну да, ну да, я заметил :) как придет счет несколько раз - народец начинает жабой давиться. Мол, как это - я столько бабла слил в канализацию?!
> а вот оплата меньше в 4-5 раз получается.
А это потому что на тех кто не ставит - вешают вообще все потери в системе. Такой вот хардкорный стимул. Заодно и краны сразу как-то так приводят в порядок. Раньше как - льется из неисправного крана - да и буй с ним. А теперь это будет означать весьма конкретный залет на бабки. Сразу все окультуривают все и краны у них идеальненько работают. Кто же хочет сливать в канализацию бабло? :)
О. Уже несколько отметились которых "не разводят". Кроме как поставить счётчик дальше у них мысли не идут. Ну ничего, помогу чем смогу.
Так вот. Когда ставится счётчик появляются ещё общедомовые нужды. Соответственно ставится ещё один счётчик на дом. Показания с которого записываются, естественно, только на тех у кого дома счётчик. Остальные, без счётчиков, уже своё оплатили. Это первое такое маленькое недовольство. Дальше начинается веселей. Начинают устанавливать счётчики всё больше народа. Вот теперь начинается веселуха. Знакомый рассказывал про пример одного городишки. Там всё обвешали счётчиками. В результате стало рвать трубы магистралки, межрайонные. Ну а как иначе - на каждом счётчике падение давления. Когда их очень много это прилично сказывается. В результате в час наибольшего расхода приходилось повышать давление (до верхних этажей вода не доходила). Тут то и сказались трубы неменянные с советской власти. Это второе недовольство - побольше.
Вот здесь, судя по всему, надо объяснить как поставщики ресурсов работают. Представь что водоканал получал определённое количество денег. Часть разворовывал, часть на ремонты отправлял. И тут все такие умные понаставили счётчиков. В результате платят наааамного меньше денег. Что, начальству тамошнему надо свои хотелки спрятать и не воровать? Ага, щаззз. Это минус ремонты и развитие скорее. Некоторые поступают интересней. Вот централизованная горячая вода. Туда простых счётчиков понаставили люди. А открывают кран - там чуть тёпленькая. И вынуждены сливать несколько минут воду для того что бы горячая пошла. Просто генерация умная - они днём запросто уменьшат температуру в системе. А платить заставят как за горячую. Ну и дальше таких наколок вагон.
А теперь ещё интересней. Вот для таких умных, понаставивших счётчики, наше государство уже придумало меры. Социальные нормы называется. Вот здесь про этот эксперимент написано http://www.rg.ru/2012/09/05/socnormi.html . А как заставить население, обвешавшиеся счётчиками и экономищие всё что можно, платить как раньше а то и больше ты уж догадаешься.
Ах да, совсем забыл. Судя по всему либо ответившие живут в регионе где считается коммуналка хз как, либо у них семьи нет. Когда дома один маленький ребёнок (не говоря о двоих) выгоды от счётчика никакой, а то и хуже становится.
> ещё один счётчик на дом. Показания с которого записываются, естественно, только
> на тех у кого дома счётчик. Остальные, без счётчиков, уже своё оплатили.У нас делают умнее: на тех кто без счетчика вешают всю дельту между общедомомым потреблением по общему счетчику и индивидуальными деленную на число индивидуалов без счетчика. Получается совершенно конский расход - типа 60 кубов в месяц на персону. Который персона без счетчика и оплачивает. Тогда как по факту даже самый наглый гражданин врядли сливает более 10 кубов если не льет круглыми сутками воду. Получается просто убер-невыгодно (те кто без счетчикиа оплачивают вообще все утечки системы) и все дружно драпают на счетчики.
вауууууу. А закон можно узнать по которому они так отлично высчитывают.
>> Это влияет только на времяПо такой логике и SSD - совершенно бесполезная штука. А что, есть же HDD, они работают, просто медленее. Но вот, привыкнув к скорости, на "тормоза" возвращаться уже раздражает, "ну давай, чего ж такой медленный", проверено.
>> Вы когда чистите зубы, во время самой чистки выключаете воду для экономии ресурсов?
Конечно. Зубы чистятся 3 минуты, а на потребление воды стоит счетчик.
SSD для хранения swap, совершенно бесполезная. мрут как мухи,
по той же причине бесполезная на файлсерверах - приходится менять каждые 3-4 месяца.
а HDD стоят и работают годами...Вам еще нужны SSD и вы готовы терять свои данные?
может сравним по такому параметру?
Вот, откровенно говоря, у меня такие же практические данные.Но, с другой стороны, в магазинах уже продаются SSD с _пятилетней_ гарантией. Врут, или не договаривают всего?
для soho user - это будет 5 лет.а вот при тестировании в роли внешнего journal device для ext4 у машинки из первой двадцатки top500, прослужил меньше полугода. после чего схему с ssd заменили на обычные 2.5" диски.
и их нужно менять сильно реже.
> Врут, или не договаривают всего?Не договаривают. Если вы активно пишете на диск - SSD околеет довольно быстро. Но при обычном десктопном использовании это не произойдет. Бывают корпоративные SSD на основе SLC флеша. Отличаются лютой скоростью и куда более приличным ресурсом. Взамен обладают скромной емкостью при весьма лютой цене. Зато живут существенно дольше и работают быстрее. Но нишевая хрень.
В общем SSD - отличная вещь. Для нагрузок не связанных с активной постоянной записью. Иначе будете менять их чаще чем лампочки.
> Вам еще нужны SSD и вы готовы терять свои данные?А на десктопе например при аккуратном использовании прослужит дофига. Я вот за год протер на 1% судя по показометрам смарта. Я думаю он отойдет в утиль по причинам отличным от wearing-а. Зато система с SSD - просто реактивная. Программы запускаются мгновенно, etc. Красота.
>> - Запуск программ по более-менее продвинутым критериям (событиям).
>Вы когда чистите зубы, во время самой чистки выключаете воду для экономии ресурсов?Он их чистит по событию, только перед тем как их могут увидеть :)
systemd для ленивых, которые уповают на суперпомошника, потому что их не принимают в сообщество из-за их лени, тупости и огромного желания ездить на феррари. Вот они и пиарят это феррари - путь хомячков или в хомячки.
Ещё раз. Какие проблемы он решает? Не "какие технические рещения применены", а "было так, я (пользователь/админ) вот этого сделать не мог, а теперь могу" или "переход на systemd в той-то ситуации экономит столько-то денег". Именно "как мне "Сапсан" сэкономил деньги/здоровье", а не "какие крутые у нас нанотехнологии".Тут из подобного только первый аргумент, только он ложный - почитайте маты на то, насколько действия systemd непрозрачны и как сложно понять, что пошло не так. Жалоб хватает.
вот по этой причине systemd и монстр, собирают сразу чтоб меньше проблем вылазило тот же udev для этого и втянули, а захочешь катализировать словишь баги и обломишься.
>- Простой мониторинг и рестарт фоновых сервисов.А с этим раньше были проблемы?
>- Упрощение и ускорение впихивания нового сервиса в систему в разы.
В чем ускорение то? Если запускаешь что-то нетривиальное, обычно наоборот надо хорошо подумать о зависимостях, прочитать кучу манов, чтобы понять куда и как прописывать. В upstart/sysv скрипты есть в пакетах, и никаких лишних телодвижений предпринимать не надо.
>- Параллельный старт сделанный не через задний проход.
Вы думаете, скажем upstart, он сделан неправильно? Да и не надо это на серверах. raid контроллер раскручивает диски по 5 минут. Мне от ускорения загрузки не тепло и не холодно. Если была бы возможность hot restart, без переинициализации оборудования, как в солярке, это было бы интересно. Но как раз ее то нет.
>- и без дрюкания на каждый 20кб демон 800кб интерпретера с поводом и без, так что взлет интерпретера занимает больше чем старт сервиса.
Вы запускаете демоны 10000 раз в секунду? Нет? Тогда не все ли равно?
- Запуск программ по более-менее продвинутым критериям (событиям).
Вообще не понял о чем речь. Причем здесь системы загрузки?На самом деле в основе systemd лежат здравые принципы, и она может облегчить чем-то жизнь. Просто я хочу показать, что вводимые ею новые возможности не являются killer feature для системы. Проблемы не в systemd, а в том что ее кодит некомпетентный придурок, который не может писать совместимый с другими код, и необходимо перелопачивать всю систему, чтобы его поделка работала, при этом не предоставляя в замен чего-нибудь хоть сколько значимого. Примеры usrmove, журналом, веб сервером уже набили всем оскомину.
> автомобили - это из разряда "чинить то, что не поломано" (ведь есть
> лошади)Очень многие автомобили - именно такие. К примеру, у большинства легковых авто сейчас крашенные сверху бамперы - верх идиотизма.
> сейчас крашенные сверху бамперы - верх идиотизма.Действительно, в случае лошадей - "нет бампера - нет проблемы" :)
>> сейчас крашенные сверху бамперы - верх идиотизма.
> Действительно, в случае лошадей - "нет бампера - нет проблемы" :)Автомобили - действительно проблема. Конкретнее - личный транспорт.
Зато теперь каждая блондинка за рулем может мнить себя водителем, а прыщавый недоросль с systemd - админом.
> Зато теперь каждая блондинка за рулем может мнить себя водителем, а прыщавый
> недоросль с systemd - админом.Вы уж определитесь - то вы вопите что systemd сложен, то каждый недоросль. Получается что или вы сами себе противоречите, или что наобум взятый недоросль - умнее вас, а блондинка - лучше водит автомобиль чем вы.
>> Зато теперь каждая блондинка за рулем может мнить себя водителем, а прыщавый
>> недоросль с systemd - админом.
> Вы уж определитесь - то вы вопите что systemd сложенНикто не "вопит". У sysvinit вполне четко ограниченный функционал, описание вполне укладывается в несколько страниц мана - туда не тянут по первому чиху 100500 новых крутилок "гибридных спящих режимов" и "полей с временем жизни временного файла". И gdb не нужен для отладки...
Так что для рядового системного администратора - systemd сложнее для понимания и для отладки. Вопить же, что у него стало быстрее грузиться до любимых игрушек и мерять сложность init-скриптов в количестве строк - может любой 15-летний оболтус.
> Получается что или вы сами себе противоречите
Как обычно - недоросли не доросли до логики.
Ну бред же! В том то и дело что эти километровые портянки скриптов слишком легко изменить, вот и клепают все свершенно разное, несовместимое. Ушел старый админ- все, 5 летние его "наработки" в этих портянках только он один и может понять. Только идиоты или админы локалхоста это не понимают или петросянят прикидываются. Невозможность обновления системы после правки этих жизненно важных скриптов - вот главный их недостаток. И вся фирма потом должна молиться на того кто "умеет разбираться" в этих макаронах. Это в первую неделю 2-3 строчки очевидных правок, через пол года уже больше, через годы уже практически переписаная система инициализации, в которой автор только и может разобраться (или он так думает что может).
>[оверквотинг удален]
> скриптов слишком легко изменить, вот и клепают все свершенно разное, несовместимое.
> Ушел старый админ- все, 5 летние его "наработки" в этих портянках
> только он один и может понять. Только идиоты или админы локалхоста
> это не понимают или петросянят прикидываются. Невозможность обновления системы после правки
> этих жизненно важных скриптов - вот главный их недостаток. И вся
> фирма потом должна молиться на того кто "умеет разбираться" в этих
> макаронах. Это в первую неделю 2-3 строчки очевидных правок, через пол
> года уже больше, через годы уже практически переписаная система инициализации, в
> которой автор только и может разобраться (или он так думает что
> может).Никогда не видел КИЛОМЕТРОВЫХ RC-скриптов. Самое большое и страшное успешно осиливалось за пол дня. Ключики -x и -e у /bin/sh очень некисло помогают разбираться в подобном.
Проблема со сложностью инитскриптов в общем случае надумана.
То есть атомы надуманы потому что их не видно? И каким образом ключики потогут разобраться в самой логике происходящего если человека придумавшего логику уже нет по близости ? И вариант с systemd - милионы компов используют, отлаженное ядро, микроскопические текстовые юниты с более строгим ситнаксисом чем всеобьемлющие скрипты на которых хоть 3Д рендер пиши. На самом деле всем все понятно, но прикинуться надо обязательно. Не на локалхостов нацелена systemd, а на лондонские сырьевые биржы и прочие контроллеры газораспределительных станций.
>контроллеры газораспределительных станций.qnx
ты бредишь.
покажи хоть один такой скрипт или петросян.
Ну бред же! А на чем по вашему будут писать кастомные скрипты к systemd? Также на shell. Оверинжиниринг видно а профит нет.
>[оверквотинг удален]
> скриптов слишком легко изменить, вот и клепают все свершенно разное, несовместимое.
> Ушел старый админ- все, 5 летние его "наработки" в этих портянках
> только он один и может понять. Только идиоты или админы локалхоста
> это не понимают или петросянят прикидываются. Невозможность обновления системы после правки
> этих жизненно важных скриптов - вот главный их недостаток. И вся
> фирма потом должна молиться на того кто "умеет разбираться" в этих
> макаронах. Это в первую неделю 2-3 строчки очевидных правок, через пол
> года уже больше, через годы уже практически переписаная система инициализации, в
> которой автор только и может разобраться (или он так думает что
> может).Вот, например, я - классический админ локалхоста и пары мелких специфических сервачков в тепличных условиях локалки фирмы (особых нагрузок нет, кул-хацкеров нет, режим 24/7 не требуется, в общем, тот же локалхост). Я в обязательном порядке использую системы контроля версий для всех конфигов (и не только). Я документирую любые вносимые изменения в специально отведенный маленький багтрекер. Ничего сверхоригинального - я "админю" также как разрабатываю софт (только ответственность поменьше). Админы предприятия (типа "настоящие админы") делают еще более расширенно (ведут "базу знаний", faq'и всякие, рисуют структурные схемки всего и т. п.). И вы правы - я совершенно не понимаю описываемые вами "страшные проблемы".
Решить организационные проблемы исключительно техническими средствами невозможно.
> Никто не "вопит". У sysvinit вполне четко ограниченный функционал, описание вполне
> укладывается в несколько страниц манаДа, руководстпо пилота по "боингам" несколько более объемисто чем "но, пошла! Дыщ!". Следует ли отсюда что все пилоты боингов - лошпеды и надо вернуться на гужевой транспорт?
Если бы systemd по сравнению со старыми init-скриптами был Боингом - вопросов бы и не было. А так - это та же гужевая повозка, только с крыльями, иллюминаторами и реактивными двигателями, которая все так же перевозит по земле все те же грузы, что и гужевая повозка, но требует вышеупомянутое руководство пилотов Боинга.
> Никто не "вопит". У sysvinit вполне четко ограниченный функционал,Замечательно. А я хочу больше функционала. И вполне себе формирую спрос и голосую ногами. Правда просто? :)
> есть лошадиопять полено пришло про лошадей гутарить. в каждый тред про леннарта ходит и про лошадей рассказывает. местный прежевальский, мля.
>> есть лошади
> опять полено пришло про лошадей гутарить. в каждый тред про леннарта ходит
> и про лошадей рассказывает. местный прежевальский, мля.Хороший петросянобатхерт, молодец. Значит в точку попал.
Конечно, мальчик, конечно. Все просто бугуртуют от твоего знания http://lol.i.trollyou.com/LOL-I-TROLL-YOU.png
За любимую бубунту обиделся ? :-) Ну так если ее производят, то находят и пользователей :-))
>> есть лошади
> опять полено пришло про лошадей гутарить. в каждый тред про леннарта ходит
> и про лошадей рассказывает. местный прежевальский, мля.Это не Пржевальский, это user294. И да, читать этого индивида - то еще удовольствие.
> Это не Пржевальский, это user294.Простите, про лошадей не я начал. Но поддержал, ибо кто ж виноват что современные системы становятся сложнее и фичастее? Да, они больше напоминают "боинг" чем "бричку". Ну и бортовой компьютер для управления всем этим уже перестает смотреться роскошью.
> systemd - это из разряда "чинить то, что не поломано"Да, совсем не поломано. Подумаешь, для типового сервиса надо 2-3 портянки на страницу выписывать. И потом еще отладить чтобы не глючило даже в краевых ситуациях. А если надо взлететь скажем не раньше чем некий сетевой интерфейс поднялся - вообще счастья полные штаны. Не, ездить конечно можно и на лошадях, но автомобили - практичнее и функциональнее. И кондей в салоне - далеко не лишний артефакт. Особенно когда за бортом +30 например.
Окститесь, зависимости прописываются даже в sysV в дебиане. И там, где приходится писать портянки (сложные случаи) ровно их же вы будете писать с systemd - потому что его параметрами не обойдётесь. А для простых случаев там два десятка строк, берущихся из скелета. При этом имеете полнуж прозрачность происходящего, чего в systemd нет и близко.
> случаев там два десятка строк, берущихся из скелета.Распиханых по 2-3 закоулкам и прочая. Супротив 3 строк в одном месте полный сакс. И да, если что - я таки запускаю кастомные сервисы и все это ощутил на лично своей шкуре. Как оно мне удобнее - выводы сделал, а фанаты ископаемых могут блеять все что угодно. Пусть хоть на каретах дефилируют, только я тут не при чем.
Когда вы запускаете типовой сервис, а кастомизировать вы его будите уже на shell и упс у вас будет такая же портянка но в 2 местах.
> Когда вы запускаете типовой сервис, а кастомизировать вы его будите уже на shellЯ согласен пописать на шелл в 5% случаев. Я не согласен это делать в остальных 95%.
Кстати, про трусы была реальная история. Зря потёрли ;-)
> Как будто это что-то хорошее. Раньше разобраться мог средний админ, а сейчас
> не каждый программист это может сделать.Да, всяким изенам и нагуалам придется теперь использовать что-нибудь попроще :)
не порите ерунды. я человек со стороны ито разобрался прочитав хауту на википедии. про шеллскрипты разобраться было сложнее ибо можно так можно так, а можно вообще вот так, а в дебьяне пожалста вот так и сиди думай а как мне надо? а как правильнее?
> не порите ерунды. я человек со стороны ито разобрался прочитав хауту на википедии.О, ты-то нам и нужен, золотая голова!
http://bugs.debian.org/669101
Покажи результат своего "разбирательства" и помоги с багом.
Дальше можно http://bugs.debian.org/692120
Ну, и далее по списку... http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dis...Поправите хоть 3-4 проблемы - я готов буду поверить, что вы хоть в чем-то "разобрались". Дерзайте!
> про шеллскрипты разобраться было сложнее ибо можно так можно так,
> а можно вообще вот так, а в дебьяне пожалста вот так
> и сиди думай а как мне надо? а как правильнее?"Правильнее" - так, как требуют стандарты и как принято в конкретном дистрибутиве. В Debian все принятые технические нормы описаны в Debian Policy.
Всех предупреждали, надо было учиться, systemd не вчера появился
> Всех предупреждали, надо было учиться, systemd не вчера появилсяГлупо учиться всему подряд или только ради учебы. Не хочу я, к примеру, учиться автомобили продавать.
Существовавшие до systemd системы инициализации - в нормальных дистрибутивах со своими обязанностями справляются настолько, что о них можно *забыть* и решать прикладные задачи. Не ломалось - не чини.
>> Всех предупреждали, надо было учиться, systemd не вчера появился
> Глупо учиться всему подряд или только ради учебы. Не хочу я,
> к примеру, учиться автомобили продавать.
> Существовавшие до systemd системы инициализации - в нормальных дистрибутивах со своими
> обязанностями справляются настолько, что о них можно *забыть* и решать прикладные
> задачи. Не ломалось - не чини.Они не решают проблемы обновления дистрибутивов. Они не справляются с задачей, если умник поменяет 1 строку не в том якобы "очевидном и простом" скрипте. Простота .bash это иллюзия. Это полноценный язык программирования. Такого там каждый в своем огороде наворочают что только снос корневой системы и полная переустановка спасает.
> Они не решают проблемы обновления дистрибутивов.Выберите нормальный дистрибутив, а не федору какую-нибудь.
> Они не справляются с задачей, если
> умник поменяет 1 строку не в том якобы "очевидном и простом"Увольте умника и наймите системного администратора. "Умник" вам и конфиги systemd поломает - в чем разница?
> Простота .bash это иллюзия. Это полноценный язык программирования.
Это полноценный скриптовый язык для задач системной автоматизации.
>> Они не решают проблемы обновления дистрибутивов.
> Выберите нормальный дистрибутив, а не федору какую-нибудь.
>> Они не справляются с задачей, если
>> умник поменяет 1 строку не в том якобы "очевидном и простом"
> Увольте умника и наймите системного администратора. "Умник" вам и конфиги systemd
> поломает - в чем разница?
>> Простота .bash это иллюзия. Это полноценный язык программирования.
> Это полноценный скриптовый язык для задач системной автоматизации.поломанные конфиги systemd намного проще исправить чем поломанная километровая портянка скриптов кишками наружу. Достали уже прикидываться. Часть отлаженного проверенного кода священных скриптов, наиболее общая, переписана на с и убрана от шаловливых ручек. Вот и все.
systemd не поломать там ломать нечего все гвоздями прибито намертво, это же инерпрайз нестандартные решения только за денежку и от redhat.
Наконец-то линуксом не смогут пользоваться такие, как ты долбодятлы! Я буду счастлив.
Отличный классический пример наглой лжи.
udev сыроват - не может нормально переименовывать интерфейсы
У меня переименовывает, в чем ненормальность?
при наличии 3х сетевых карт eth0-2 он переименовыет 1 или 2 интерфейса и то в зависимости от порядка, как они определились, если же попробовать указать переименовывание eth0,1 и 3, то тогда иногда срабатывет "как надо"
как так
железо и конфиг udev остались неизменными - fedora 16 ещё всё ок :)
vim /etc/udev/rules.d/70-persistent-net.rulesK.O.
Мне не нравится systemd только тем, что initscripts были гораздо удобнее для админа.
Например chkconfig --list и сразу видно что включено, что выключено и на каких уровнях. Теперь надо извращаться grep'ами и awk'амиТак же bash-completion превосходно работал с "service", и не используя ничего, кроме нескольких нажатий на <tab> я мог сразу сказать, какие демоны установлены, какие нет, запустить и проверить состояние в одно-два нажатия на <tab>+<enter>. Теперь надо извращаться grep'ами и awk'ами
Написание файла-сервиса по шаблону у меня никогда не отнимало более 15 минут для системы initscripts. Теперь надо извращаться grep'ами и awk'ами (копаясь в манах systemd)
Могу продолжить этот список, но врядли кто-то будет читать такое кол-во букв...
> и не используя ничего, кроме нескольких нажатий на <tab> я мог сразу сказать, какие демоны установлены, какие нет, запустить и проверить состояние в одно-два нажатия на <tab>+<enter>. Теперь надо извращаться grep'ами и awk'амиВы можете это сделать только потому что кто-то уже позвращался с grep'ами и awk'ами
ага, ключевое слово здесь "шаблоны" мухаха)) вот же смешно, когда такому админу легче загуглить, нежели -h дописать.
> Мне не нравится systemd только тем, что initscripts были гораздо удобнее для
> админа.
> Например chkconfig --list и сразу видно что включено, что выключено и на
> каких уровнях. Теперь надо извращаться grep'ами и awk'ами# systemctl list-unit-files --type=service
> Так же bash-completion превосходно работал с "service",В OpenSuSE bash-completion работает с systemd
> и не используя ничего, кроме нескольких нажатий на <tab>
> я мог сразу сказать, какие демоны установлены,# systemctl list-unit-files --type=service
> какие нет, запустить и проверить состояние в одно-два нажатия на <tab>+<enter>.
> Теперь надо извращаться grep'ами и awk'ами# systemctl list-units --type=target
> Написание файла-сервиса по шаблону у меня никогда не отнимало более 15 минут
> для системы initscripts. Теперь надо извращаться grep'ами и awk'ами (копаясь в
> манах systemd)Но корявость systemd не в этом.
> # systemctl list-unit-files --type=serviceT.e вот "ЭТО" гораздо удобнее:
systemctl list-unit-files --type=service
acpid.service enabled
alsa-restore.service static
alsa-store.service static
anaconda-shell@.service static
anaconda@.service static
apg@.service static
arp-ethers.service enabled
atd.service enabled
auditd.service enabled
autovt@.service disabled
avahi-daemon.service enabled
backuppc.service disabled
bluetooth.service enabled
Чем это:chkconfig --list
hsqldb 0:off 1:off 2:off 3:off 4:off 5:off 6:off
ipsec 0:off 1:off 2:off 3:off 4:off 5:off 6:off
iscsi 0:off 1:off 2:off 3:on 4:on 5:on 6:off
iscsid 0:off 1:off 2:off 3:on 4:on 5:on 6:off
jexec 0:on 1:on 2:on 3:on 4:on 5:on 6:on
кому как
>> # systemctl list-unit-files --type=service
> T.e вот "ЭТО" гораздо удобнее:
> Чем это:Те же яйцы, только вид с боку.
Да нет, не теже...
На йух мне видеть состояние демона, который у меня даже не установлен?И весь этот список бредовых команд из которых реально работает всего штук 10, из которых, в свою очередь реально нужно от силы 4 ???
P.S.
Зачем люди спорят, которые даже не пользуются сабжем?
То есть табличку читать сложнее чем список ? Ну может леннарт и делал свое подели для тех, кто даже в екселе работать не может :-)
> Мне не нравится systemd только тем, что initscripts были гораздо удобнее для
> админа.Ты слишком стар, тебе инноваций никогда не понять!
>> Мне не нравится systemd только тем, что initscripts были гораздо удобнее для админа.
> Ты слишком стар, тебе инноваций никогда не понять!А ты ещё зелёный чайнег, чтоб отличить инновации от старого баяна, который никому не был нужен.
Теперь, с массовым отупением юзеров Линуха, стало проще пропихнуть эту фичу.
> Теперь, с массовым отупением юзеров Линуха, стало проще пропихнуть эту фичу."Теперь, с отупением водятлов, стало намного проще пропихивать АКПП, бортовой компьютер с отображением пробок и кондиционер в салоне. То-ли дело ямщики были!".
>> Теперь, с массовым отупением юзеров Линуха, стало проще пропихнуть эту фичу.
> "Теперь, с отупением водятлов, стало намного проще пропихивать АКПП,
> бортовой компьютер с отображением пробок и кондиционер в салоне.Вот, так плавно мы и подошли о необходимости автомобиля в городе, особо в пробочных городах.
Ибо выше перечисленные фишки нужны только чайнегам и залётным, не знающим дороги.Поэтому, все, кому нужен systemd, - пи...дуйте на Венду или МакОСь. :-P
> Ибо выше перечисленные фишки нужны только чайнегам и залётным, не знающим дороги.Да, и ABS - для ламеров. И подушки безопасности - лишняя фигня. Можно же и на бричке ездить без всей этой хреноты. Никто и не сомневается что можно. Правда что-то спроса на брички нет. Хоть они и дешевле в производстве из-за отсутствия "всякой фигни".
>> Ибо выше перечисленные фишки нужны только чайнегам и залётным, не знающим дороги.
> Да, и ABS - для ламеров.Конечно, погоняй с АБС по гравийки иль с заносом на льду - тебе нужон занос,
а оно само сцуко едет, ну чем не Windows.
> Конечно, погоняй с АБС по гравийки иль с заносом на льду - тебе нужон занос,
> а оно само сцуко едет, ну чем не Windows.Бывают в жизни огорчения. Поэтому ABS и делают отключаемым, особенно на авто предназначенных для езды где попало. У автомобилей для г@внодавов даже дифференциал отрубается.
> А ты ещё зелёный чайнег, чтоб ...Жарптица, уйди! :)))
>> А ты ещё зелёный чайнег, чтоб ...
> Жарптица, уйди! :)))Улятаю, хотя весело тут с вами..
> Улятаю, хотя весело тут с вами..Ты куда? А как же мой обед?! :)
>> Улятаю, хотя весело тут с вами..
> Ты куда? А как же мой обед?! :)Так он тебя известной субстанцией и накормил
>>> Улятаю, хотя весело тут с вами..
>> Ты куда? А как же мой обед?! :)
> Так он тебя известной субстанцией и накормилА вот посоны говорят что было не так, постом ниже...
Посоны говорят, а всем как обычно...
> А как же мой обед?! :)Завтрак отдал себе! Обед разделил с собой! Ужин сожру сам! :-P
От юзеров линукс никогда не зависел и, наверное, не будет
Да ложит редхат свой инструмент на юзеров, главное доля рынка и прибыли.
> Да ложит редхат свой инструмент на юзеров, главное доля рынка и прибыли.То-ли дело гентушники, у которых система вообще хрен знает для чего. В основном для развлечения в виде постоянного переколупывания системы :)
> Например chkconfig --list и сразу видно что включено, что выключено и на
> каких уровнях. Теперь надо извращаться grep'ами и awk'амиsystemctl -t service -a
> Так же bash-completion превосходно работал с "service", и не используя ничего, кроме
> нескольких нажатий на <tab> я мог сразу сказать, какие демоны установлены,
> какие нет, запустить и проверить состояние в одно-два нажатия на <tab>+<enter>.
> Теперь надо извращаться grep'ами и awk'амиДа ты упоролся.
Кстати, service успешно отрабатывает. Злобный Леннарт ДАЖЕ ЭТО ПРЕДУСМОТРЕЛ!> Написание файла-сервиса по шаблону у меня никогда не отнимало более 15 минут
> для системы initscripts. Теперь надо извращаться grep'ами и awk'ами (копаясь в
> манах systemd)initscripts прибиты к мозгу гвоздями на клею? И мозг уже ни с чем не совместим?
> Могу продолжить этот список, но врядли кто-то будет читать такое кол-во букв...
Да, не нужно.
Я знаю одну операционную систему, построенную по принципу: "Upgrading operating system doesn't require you to upgrade yourself".Но сейчас же опять начнут кричать, что у неё лицензия некошерная. :)
> Я знаю одну операционную систему, построенную по принципу: "Upgrading operating system
> doesn't require you to upgrade yourself".MSDOS 5.0 -> 6.22 ?
> "Upgrading operating system doesn't require you to upgrade yourself".Хреново, знаете ли, когда компьютер апгрейдится, а админ - наоборот.
Хреново, знаете ли, когда вы с 15-летним опытом работы с Юниксом понимаете, что ни хрена не можете сделать с очередной вышедшей версией.Дело в том, что люди с 15-летним опытом работы получают, прямо скажем, не три с половиной копейки в зарплату -- и "посидеть, поразбираться" для них -- это некислый ущерб для работодателя.
> Дело в том, что люди с 15-летним опытом работы получают, прямо скажем,
> не три с половиной копейки в зарплату -- и "посидеть, поразбираться"
> для них -- это некислый ущерб для работодателя.Сесть и разобраться с чем бы то ни было это их прямая обязанность и отговорки "я так не умею" и "это слишком сложно" являются показателем их некомпетентности.
> Сесть и разобраться с чем бы то ни было это их прямая обязанностьВот это вот иллюзии ваши всё.
Отдел инженеров по эксплуатации -- это не отдел НИОКР.
> Отдел инженеров по эксплуатации -- это не отдел НИОКР.Правильно. Поэтому при случае отработанная партия выкидывается на улицу и набирается новая, если старая переобучаться уже не может. Ну, когда возить товары автомобилями становится явно эффективнее чем ложадями а водители их ямщиков оказываются никудышными.
> Хреново, знаете ли, когда вы с 15-летним опытом работы с Юниксом понимаете,Вполне нормально, когда ямщик вдруг обнаруживает что его 20 лет езды на конях совсем не засчитываются за опыт вождения автомобиля, пилотирование самолета или что там еще.
> - Обеспечена поддержка сборки udev и systemd без поддержки blkid и kmod, что может быть востребовано разработчиками встраиваемых систем, желающих свести к минимуму число используемых зависимостей;Ты смотри... А как воняли на разработчиков генты недавно (http://www.opennet.ru/openforum/vsluhforumID3/87370.html), что те "выкидывают то, что не понимают"...
Ну так чует кошка, чье мясо захавала!
Ну и опять же "двойные стандарты" у поттеро-умников весьма в почете.
> что те "выкидывают то, что не понимают"...Вот конкретно те индивидуалы делали что-то совсем невменямое. Рассовать код шаред либы обратно по закоулкам + выпилить варнинги это конечно огуительный ченжлог и фантастический вектор развития проекта.
>> - Обеспечена поддержка сборки udev и systemd без поддержки blkid и kmod, что может быть востребовано разработчиками встраиваемых систем, желающих свести к минимуму число используемых зависимостей;
> Ты смотри... А как воняли на разработчиков генты недавно (http://www.opennet.ru/openforum/vsluhforumID3/87370.html),
> что те "выкидывают то, что не понимают"...Боятся форков. Очень боятся.
>>> - Обеспечена поддержка сборки udev и systemd без поддержки blkid и kmod, что может быть востребовано разработчиками встраиваемых систем, желающих свести к минимуму число используемых зависимостей;
>> Ты смотри... А как воняли на разработчиков генты недавно (http://www.opennet.ru/openforum/vsluhforumID3/87370.html),
>> что те "выкидывают то, что не понимают"...
> Боятся форков. Очень боятся.Как же им не бояться, ведь есть, как минимум, несколько человек в мире, которые если сделают форк, то вся экосистема тут же на него и уйдет. Пока они лояльны, но все ведь может и поменяться.
> Ты смотри... А как воняли на разработчиков генты недавно (http://www.opennet.ru/openforum/vsluhforumID3/87370.html),
> что те "выкидывают то, что не понимают"...Они "без blkid и kmod" сделали оригинально --- выкидывают вместе с функциональностью
(не понимающие кода гентушники функциональность сохранили)."So you think it's better to do nothing, load nothing, and break things?"
борьба за власть за то, что первое стартанет после ядра. Не ожидал, что этим так страдают линуксоиды. Печалька. Если уж на то пошло - то нужно после старта ядра еще и предлагать через меню как в грубе выбор systemd или udev или еще что
> борьба за власть за то, что первое стартанет после ядра. Не ожидал,
> что этим так страдают линуксоиды. Печалька. Если уж на то пошло
> - то нужно после старта ядра еще и предлагать через меню
> как в грубе выбор systemd или udev или еще чтоНет, просто парсить интерпретатором километровые самописные скрипты в таком очень важном деле как инициализация - идеотизм, за более чем 15 лет можно уже общую часть выделить и не вилосипедить в каждой деревне свои скрипты с логикой понятной только автору.
ну в общем да - 15 километров костылей не ЪМеня всегда удивляло, что инит идет через костыльные скрипты. Ничего плохого в скриптах нет, но и порядка тоже нет. Можно было бы пофантазировать на предмет архитектуры: типа событийная модель, pubsub все дела observers/subj системная шина. Шлются евенты - обработчики реагируют... Пограничные состояния инитов всегда были источником проблем имхо.
Ну да, ну да. Аноним же не в курсе, на каких принципах построены Unix-системы.
> Ну да, ну да. Аноним же не в курсе, на каких принципах
> построены Unix-системы.ты про это?
http://pixelstech.net/article/index.php?id=1336304966
А теперь все сидим и дружно думаем - при чём тут UNIX?..
> скрипты с логикой понятной только автору.Давайте так. Берете, указываете три скрипта из /etc/init.d/ в Debian Squeeze, берете в каждом интересный вам кусок кода на экран - и я вам подробно объясняю его "логику" и что он делает. Как вы правильно догадались, я не являюсь автором всех инит-скриптов в Debian.
В качестве благодарности меня устроит если вы хоть изредка будете интересоваться как пишутся слова в русском языке, прежде чем очаровывать своей безграмотностью.
Подходит?
>> скрипты с логикой понятной только автору.
> Давайте так. Берете, указываете три скрипта из /etc/init.d/ в Debian Squeeze,
> берете в каждом интересный вам кусок кода на экран - и
> я вам подробно объясняю его "логику" и что он делает.
> Как вы правильно догадались, я не являюсь автором всех инит-скриптов в
> Debian.
> В качестве благодарности меня устроит если вы хоть изредка будете интересоваться как
> пишутся слова в русском языке, прежде чем очаровывать своей безграмотностью.
> Подходит?За одним исключением, эти скрипты уже лет 5-7 правились "супероплачеваемыми гуру юникса", но после того как вся гоп команда была поймана за воровством денег, были уволены. И дистрибутив ессно не дебиан. И чинить надо быстро, ибо 3000 рабочих мест простаивают.
> За одним исключением, эти скрипты уже лет 5-7 правились "супероплачеваемыми гуру юникса",
> но после того как вся гоп команда была поймана за воровством денег, были уволены.
> И дистрибутив ессно не дебиан. И чинить надо
> быстро, ибо 3000 рабочих мест простаивают.Никаких проблем. Время, сроки, деньги - я готов услышать ваше предложение.
Но мы отвлеклись. Итак, в публично доступном хорошем дистрибутиве - найти скрипты с "логикой, понятной только автору" вы не смогли. Все верно?
> За одним исключением, эти скрипты уже лет 5-7 правились "супероплачеваемыми гуру юникса",
> но после того как вся гоп команда была поймана за воровством
> денег, были уволены. И дистрибутив ессно не дебиан. И чинить надо
> быстро, ибо 3000 рабочих мест простаивают.То есть, вчерашний виндузятник, с опытом работы "в консоли" на PowerShell, пришел админить контору, которая 7 лет работала на Юниксе? Так сразу и говори, что shell не осилил, а не рассуждай про пользу windows-подобных систем инициализации на Линуксе...
Мышкой щелкнуть на названии сервиса да из меню пункт выбрать еще проще, однозначно...
>> борьба за власть за то, что первое стартанет после ядра. Не ожидал,
>> что этим так страдают линуксоиды. Печалька. Если уж на то пошло
>> - то нужно после старта ядра еще и предлагать через меню
>> как в грубе выбор systemd или udev или еще что
> Нет, просто парсить интерпретатором километровые самописные скрипты в таком очень важном
> деле как инициализация - идеотизм, за более чем 15 лет можно
> уже общую часть выделить и не вилосипедить в каждой деревне свои
> скрипты с логикой понятной только автору.О, да - пара команд и switch на шелле это просто п..дец какая непонятная логика) Перестаньте уже смешить народ, а..
А че сразу битва между системд и скриптами и все. Давайте тогда уж сразу с упстартом сравним. Итак, начнем:1. Упстарт тоже умеет перезапускать процессы.
2. Тоже умеет грузить их параллельно и учитывать зависимости.
3. Упстарт запоминает состояние отработки сервисов и это можно использовать при запуске следующих сервисов.
4. Упстарт умеет отслеживать зависимости, причем как с условиями И так и с условиями ИЛИ.
5. Упстарт умеет скрипты - умеет скрипты как "скрипты инициализации", умеет скрипты как "пре" и "пост" скрипты в теле самого конфига, для запуска демона из этого самого конфига. Умеет использовать конфиг как запускаемый скрипт.
6. А еще у него нет "своего блэкждека и шл.х", в виде бинарных логов, qr кодов и веб-сервера(сарказм - ждите в следующем выпуске системд - зауск приложений для андроид, прямо из системд).
7. А еще, упстарт зарелизился раньше, раз уж мериться письками, давайте и это учитывать.И киллер фич полезных в этом списке как-то побольше чем в списке про системд. Упстарт дает из коробки совмещать два подхода инициализиции, а можете выкинуть один из них и использовать только второй.
И еще, ИМХО, управление процессами из консоли, не должно превращаться в череду команд и аргументов, писать зае..шся.
> И еще, ИМХО, управление процессами из консоли, не должно превращаться в череду
> команд и аргументов, писать зае..шся.Откройте для себя историю команд и ее возможности...
> Давайте тогда уж сразу с упстартом сравнимТак ведь вспомните, точно такой же срач был с появлением апстарта и точно так же старые пердуны и админы локалхоста срали кирпичами из-за того, что им надо изучать что-то новое.
> точно так же старые пердуны и админы локалхоста срали кирпичами из-за
> того, что им надо изучать что-то новое.Необходимость изучать что-то новое для выполнения старых задач - это недостаток. Ибо за это время можно изучить что-то новое для выполнения новых задач. :-)
предлагаю начать с пробелов в alias =) а там быстрее печатать и читать по английски научитесь.
Слишком категорично и напрашивается на фразу "далеко не всегда".
> Необходимость изучать что-то новое для выполнения старых задач - это недостаток....зато для меня он удачно скомпенсировался тем что я теперь пишу конфиг на 3-5 строк и в 1 месте, а не размазню с очередным, 100500-м по счету переизобретением велосипеда на шелле.
я так понимаю что именно из-за systemd /usr нельзя на отдельный раздел класть?
только отчасти
> я так понимаю что именно из-за systemd /usr нельзя на отдельный раздел
> класть?Чёрт, а я и не знал. Положил на отдельный (openSUSE 12.2). Ой, что будет, что будет!
«Философия UNIX гласит:
1. Пишите программы, которые делают что-то одно и делают это хорошо.
2. Пишите программы, которые бы работали вместе.
3. Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс»
3D редактор Blender разбей на куски с текстовым обменом. Или тот же gcc компилятор. эта замшелая фраза их прошлого тысячелетия, когда достижением была программа, которая умеет сотрировать строки. Время идет, нужны намного более сложные вещи, и обмениваются они гигабайтами в секунду, иначе никомы не нужны. И кто будет парсить глазами эти гигабайты в секунду, если даже они текcтовые?
> Или тот же
> gcc компилятор.тут ты попал в лужу. gcc -s видимо забыт - только по тому что по умолчанию gcc стирает за собой временные файлы?
>> Или тот же
>> gcc компилятор.
> тут ты попал в лужу. gcc -s видимо забыт - только по
> тому что по умолчанию gcc стирает за собой временные файлы?Давно в код GCC заглядывал? Ты сеье представляешь сколько сожрет ресурсов разпарсивание теквтовой галиматьи все 200 с лишним проходов оптимизатора по графам?
Наоборот со временем эти принципы все более и более подходят.> 1. Пишите программы, которые делают что-то одно и делают это хорошо.
Золотые слова. Ни чита теперешней лисе с блекджеком и соц. сетями...
> 2. Пишите программы, которые бы работали вместе.
Очень важный пункт! Каждая программа должна использоваться как минимум из 2-х разных мест: пользователь и тесты. А это сразу же приводит в порядок интерфейсы. Делает их внятными.
> 3. Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс»
Все правильно. В наше время легче использовать какой нибудь JSON. Для отладки и тестирования самое то. Я конечно за экономию, но времена бинарных протоколов надо оставлять для железяк и низкого уровня где действительно стоит экономить (например ядро ОС).
> 3D редактор Blender разбей на куски с текстовым обменом
Именно так. Оболочка и куча плагинов к ней. Если бы плагины писались как отдельные программы то можно применять их прям из консоли, писать скрипты. Да и вообще, сервисы фотографий типа flirk, picassa и т.д. эти старания бы очень оценили. Онлайн коллажики и т.д...
P.S. Опять же надо понимать что основной функционал в либах. А отборажение может быть разное: cli, gui, вебморда и т.д. Но это уже MVC...
>> 3D редактор Blender разбей на куски с текстовым обменом
> Именно так. Оболочка и куча плагинов к ней. Если бы плагины писались
> как отдельные программы то можно применять их прям из консоли, писать
> скрипты. Да и вообще, сервисы фотографий типа flirk, picassa и т.д.
> эти старания бы очень оценили. Онлайн коллажики и т.д...Обьем данных прокачиваемых через 3D алгоритмы представляешь? Одних текстур под 100 ТB на кадр в среднем фильме, а кроме них там ох как есть чему обмениваться. Так что скажи текстовым пайпам досвидания.
Уже сказал, PowerShell Прекрасен.(сарказм)
Библиотечные вызовы проще и быстрее выполняются. Лучше уж разбивать приложение на библиотеку и набор фронтэндов к ней, в том числе и в виде консольных утилит. Кому надо из скрипта раз в сутки вызывать методы предпочтут вызвать бинарь, а кому нужна скорость слинкуются с библиотекой.
> предпочтут вызвать бинарь, а кому нужна скорость слинкуются с библиотекой.Во, здравый подход к делу.
И что? никто не заставляет прокачивать текстом то что для этого не подходят. В данном конкретном случае надо все виды и этапы бить на либы. Писать для них обертку для запуска в консоли и вуаля... можно последовательно обрабатывать файлы из скриптов.P.S. Пайпы не только текстовые бывают. Учите матчасть.
И воторой раз под этой новостью напишу:
А теперь все сидим и дружно думаем - при чём тут UNIX?..
Unix тут не причем, systemd интерпрайз.
https://www.youtube.com/watch?v=o1lUeQVYuNs&feature=player_e...
фанбоям стоит послушать чтоб знать какие всеже проблемы решает systemd.
Хейтерам поржать над количеством народа.
> https://www.youtube.com/watch?v=o1lUeQVYuNs&feature=player_e...
> фанбоям стоит послушать чтоб знать какие всеже проблемы решает systemd.
> Хейтерам поржать над количеством народа.Молодого Билли Гейтоса (внешне) и его аргументацию включения графики в ядро ОС (лексически) сей Поттеринг только мне напоминает?
Билл всегда был более убедительным
Главное что в конце есть буква d.
и всё же. не можешь победить - возглавь. поделия потеринга сделаны не для людей, имхо. их задача усложнить простые сущности по аналогии со службами микросохта. не удивлюсь, если его спонсирует какой нить микросохт, или же даже без спонсирования - в силу желания выделиться
-
Круто же сказать - я, потеринг, подрубил вменяемые идеи в одном из важных направлений дистрибутивостроения Линукса, заменив их существенно более сложной хренью. А то, что его включают в дистрибутивы - ну, на РэдХат же смотрят. Там достаточно одного чудака в топах, чтобы принять волевое решение. Топам ведь надо бабло, а не качественный продукт