Стив Лангашек (Steve Langasek), один из активных разработчиков проектов Debian и Ubuntu, объявил (http://web.dodds.net/~vorlon/wiki/blog/Upstart_in_Debian/) об интеграции пакетов для поддержи загрузки Debian GNU/Linux с использованием системы инициализации и контроля за выполнением системных сервисов Upstart (https://launchpad.net/upstart/), изначально разработанной компанией Canonical и применяемой в дистрибутивах Ubuntu и RedHat Enterprise Linux 6, а также в проектах Maemo, Chrome OS и webOS.
Интеграция Upstart дала возможность проведения сравнительной оценки скорости загрузки дистрибутива при помощи Upstart, базовой системы инициализации sysvinit, а также доступной в репозиториях системой загрузки на базе systemd. В отличие о ранее проводимых разрозненных тестов, в которых каждая система тестировалась в разных дистрибутивах, теперь стало возможным выполнить комплексную оценку скорости работы трёх указанных систем инициализации в конфигурации, отличающейся только выбранными методами загрузки.После проведения тестирования были получены следующие результаты (http://web.dodds.net/~vorlon/debian-boot-testing/) (каждый тест повторялся три раза, для загрузки использовалась базовая установка Debian GNU/Linux без дополнительных сервисов):
- Загрузка с классической системой инициализации Sysvinit и со штатными дополнениями для распараллеливания запуска сервисов Startpar была выполнена за 3.37 сек. (максимальное время 3.42 сек.);
- Загрузка с использованием Upstart была выполнена за 3.03 сек. (максимальное время 3.19 сек.). Ускорение было обеспечено в основном благодаря оптимизации процесса монтирования разделов с учётом работы всех запускаемых процессов в совокупности;
- Загрузка с использованием systemd заняла 2.32 сек. (максимальное время 2.85 сек.), что на 45% быстрее, чем при использовании Sysvinit.
Основной причиной большого расхождения между systemd и upstart стало наличие unit-файла для запуска rsyslog, в то время как для upstart не было подготовлено соответствующего job-файла. После удаления unit-файла для rsyslog скорость загрузки с systemd увеличилась до 2.78-3.03 сек. Другим фактором стало использование в systemd встроенных служб hwclock, hostname и udev-mtab, в то время как upstart приходилось обращаться к внешним программам. Наиболее очевидное узкое место upstart, связанное с необходимостью запуска shell-интерпретатора, не является ключевым фактором, оказывающим значительное влияние на скорость загрузки.
Примечательно, что в условиях задействования job-файлов upstart демонстрирует близкие к systemd результаты и вполне может конкурировать с ним, обеспечивая большую гибкость в настройке и управлении процессом загрузки по сравнению с жестко определяемыми через unit-файлы правилами загрузки.Из недостатков проведённого тестирования можно отметить: использование эмулятора QEMU, вместо реального оборудования; измерение скорости загрузки до приглашения shell без учёта времени запуска реального десктоп-окружения и серверных служб; использование для анализа устаревшей версии утилиты bootchart, предоставляющей менее детальную информацию о процессе загрузки.
URL: http://web.dodds.net/~vorlon/wiki/blog/Upstart_in_Debian/
Новость: http://www.opennet.me/opennews/art.shtml?num=35431
Хоть бы железо описали, и точку загрузки.. Неуж-то на старом ноуте система загрузиться за 3 секунды до открытия файрфокса?
Цифры в данный момент ни о чём, хуже фороникса ..
Я на ноуте тестил так же с тремя системами инициализации.. На ноуте с одним ядром практически разницы не видно..
> использование эмулятора QEMU, вместо реального оборудования
Это же /0, т к загрузка в реальности по тому и занимает минуты, что железо инициалиируется медлено.
Тестили бы до экрана входа в систему хотябы и с реалистичным набором сервисов.
Если добавить запуск разных демонов, иксов, DE и браузера, то разница между всеми этими системами станет ничтожной. Ну а вообще автор старательно натягивает сову на глобус, делая вид, что разница между upstart и sysvinit огромна, а между upstart и systemd мала, в то время как цифры свидетельствуют об обратном.
> Ну а вообще автор старательно натягивает
> сову на глобус, делая вид, что разница между upstart и sysvinit
> огромна, а между upstart и systemd мала, в то время как
> цифры свидетельствуют об обратном.Потому что Лангашек - главный разработчик upstart и главный проталкиватель его во все дистры. В общем, симметричный гетьзефакс-ответ на http://www.0pointer.de/blog/projects/why
какие цифры? в новости вобщем-то написано почему апстарт отсаёт от системд, при равных условиях и результаты схожие
> какие цифры? в новости вобщем-то написано почему апстарт отсаёт от системд, при
> равных условиях и результаты схожиеНу да, если киллер-фичи systemd поотключать, получается похоже.
>киллер-фичи systemdДа, вэб сервера и генератора QR-кода там не хватает.
> Хоть бы железо описали, и точку загрузки.. Неуж-то на старом ноуте система
> загрузиться за 3 секунды до открытия файрфокса?
> Цифры в данный момент ни о чём, хуже фороникса ..
> Я на ноуте тестил так же с тремя системами инициализации.. На ноуте
> с одним ядром практически разницы не видно..Я тоже хотел бы узнать на каком железе они все это запускали, а то я тут на 4 пне, ноут, по 8-12 секунд жду загрузки до менеджера входа в систему.
> а то я тут на 4 пне, ноут, по 8-12 секундА у вас SSD?
На 4 пне разницы практически не будет. Преимущества upstart и systemd видны только на многоядерных системах.
> только на многоядерных системах....снабженных SSD. Просто это вообще иной класс производительности. Бывают системы где вам не надо ждать пока запустится программа. Бывает что система грузится быстрее чем вам это надоест. Бывает достаточно памяти для того чтобы забыть про SWAP насовсем, избавив себя от медленного paging совсем.
Разница - как между ракетопланом и запорожцем примерно.
> Я тоже хотел бы узнать на каком железе они все это запускали,
> а то я тут на 4 пне, ноут, по 8-12 секунд
> жду загрузки до менеджера входа в систему.В виртуальных средах примерно с такой скоростью (3 секунды) системы и загружаются, на среднем железе.
"измерение скорости загрузки до приглашения shell" - читайте всю статью
У меня не старая и с SSD, грузится за 10 секунд от граба до окна ввода логина в gdm (это включая readahead, после ввода пароля вход в гном происходит менее чем за секунду).
На upstart точно было больше раза в три (~30 секунд) - на том же самом SSD. А на ранних версиях systemd, когда не сделали кучу unit-файлов для сокет-активаций и прочих возможностей параллельной загрузки было больше 20 секунд. Но по мере написания правильных сервисов все стало хорошо.$ systemd-analyze
Startup finished in 1125ms (kernel) + 2215ms (initramfs) + 6813ms (userspace) = 10154ms$ systemd-analyze blame
534ms fedora-storage-init.service
483ms systemd-binfmt.service
415ms bluetooth.service
373ms postfix.service
352ms udev-settle.service
282ms lm_sensors.service
255ms chronyd.service
252ms console-kit-log-system-start.service
233ms systemd-logind.service
226ms ip6tables.service
224ms NetworkManager.service
222ms avahi-daemon.service
220ms iptables.service
208ms auditd.service
[...]Как видно, если вырубить плюшки типа LVM, bluetooth и тд, можно еще быстрее. Правда, непонятно, зачем их вырубать - польза иногда есть, а лишней секунды не жалко.
Я так понял используете systemd ?
У меня стандартный sys-v-init дебиановский, грузиться за 5-6 секунд до рабочего стола, минуя авторизацию. На более старых ядрах было 5 секунд, чем новее ядро тем дольше, сейчас где-то 6,5 ...
DE не пользую, раб.стол свой, старовые скрипты тоже свои.
Замер делаю тупо по окончанию работы стартового скрипта "cat /proc/uptime"
~/.mozilla перенёс на SSD раздел, так что и FF грузиться практически мгновенно, при открытии его.
У меня запускается много всякой "вкуснятины" типа монтирования nfs-шар с нескольких серверов (причем защищенных kerberos'ом, т.е. нужно целую пачку демонов запустить), почтового демона (как ретранслятор на другой smtp), IPv6 и т.д.
Поэтому загрузка всегда была довольно долгой, и способность systemd довести это время до 10 секунд меня впечатляет.5-6 секунд это с какого момента? Мне сложно сказать, что именно uptime пишет.. Тут юзерленд грузится за 6 секунд; 10 это общее время, включая загрузку ядра, инициализацию всех устройств, включая USB и почие плюшки. Это время обычно не меньше 2-4 секунд; если у вас все грузится за 6, то юзерленд за 2-3 секунды, что ли? Или это все-таки 6 секунд с начала загрузки init'а, а не общее время от нажатия "enter" в grub до рабочего стола?
Попробуйте замерить с секундомером, например :) Я реально не представляю, что именно показывает uptime.
Дома не тестировал загрузку до Shell, но на работе тестировал на AMD FX 6100, копировал загаженную тестовую систему wheezy на SSD отключил KDM/GDM/DM до приглашения login: удалось добиться загрузки за 3 секунды с системой systemd, с момента нажатия на Enter в grub..
Если честно, я тоже не знаю точно с какого момента начинает считать uptime. Но на работе замерял и по uptime и по секундомеру в руках, не более 3 секунд одинаково.
Дома AMD FX 8150, стандартный sysV, по uptime за 6 сек грузятся:
mount cifs с тремя каталогами
по мелочи ещё дохрена чего грузиться от блютуз-демона, до всяких xbindkeys и своих скриптов, но это по мелочи.
далее из тяжёлых стартуют иксы с nvidia драйвером
cairo-dock - metacity - xcompmgr - conky - xterm - и вывод через notify-send --> xfce4-notifyd файла /proc/uptime - первое число это секунды со старта ... эмм либо ядра либо процесса init
Но я думаю там разница в микросекундах, так что думаю особо не важно в какой именно момент начинает считать uptime.
Ядро собираю с
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
поэтому при старте системы процессор разогнан, после загрузки раб.стола уже запускается "cpufreq-set", и меняет governor на conservative. Разница заметна в 3-5 секунд. То ли стартовать систему с PERFORMANCE, то ли с conservative/ondemandБолее подробно в тюнинге на скорость не разбирался, тут куча информации уже проходило на opennet-е на эту тему.. И я уверен есть ещё куда тюнить.. Только оно надо ли, и так уже максимально быстро для меня =) Мне хватает.
До login без гуя - это понятно, но лично для меня не слишком иинтересно. В моем случае загружается plymouth, иксы, gtk'шные либы и тд для быстрого логина после этого.
> Наиболее очевидное узкое место upstart, связанное с необходимостью запуска shell-интерпретатора, не является ключевым фактором, оказывающим значительное влияние на скорость загрузкиНу наконец-то! По-моему это изначально было очевидно!
Bash скрипты могли оказывать влияние только за счет обращений к диску; задержки из-за интерпретации скриптов - малы. Но bash загружается в память один раз. А интерпретаторы сегодня достаточно продуктивны (что, собственно, определяет популярность python, php и других интерпретируемых языков).
> А интерпретаторы сегодня достаточно продуктивны (что, собственно, определяет популярность > python, php и других интерпретируемых языков).Как раз благодаря педону убунта тормозит и жрет ресурсы. На десктопе с полкиловатным БП это не так заметно, а вот на ARM - это пепец полный (20-30 сек), со своими скриптами и busybox у меня система грузится за 1 сек.
Поэтому я первым делом выпинываю из убунту их бидоноподелки. Заодно после этого ничего не падает, не виснет и не грузит проц.
> Поэтому я первым делом выпинываю из убунту их бидоноподелки. Заодно после этого
> ничего не падает, не виснет и не грузит проц.И получается дебиан.
> И получается дебиан.А оно и так не далеко ушло от оного. Из плюсов перед дебианом имхо:
1) Вменяемо сделанные лив+инсталл образа. И пишутся что на двд что на флеху, и можно как установить систему так и просто загрузиться в лив-сессию на посмотреть/починить/оценить поддержку железа в полном объеме/запасной парашют на случай внезапных факапов. У дебианщиков формат распостранения довольно ушибленный.
2) Нет мучений с древним софтом в дефолтной системе и адовым прыгом по граблям после подключения тестинга/анстейбла. Это позволяет получать относителььно свежий софт ("не древнее чем эн") без совершения забега по граблям. Может оно менее stable чем stable, но намного лучше чем testing/unstable, в которых случается все. Вплоть до факапа GRUB и полного загибания системы при ребуте. Зарелизнутые убунты так все-таки не факапятся. А для повседневной системы улет в внезапный unbootable может сцyкодорого обойтись порой.
3) Есть PPA на случай если охота свежака. Те же дебианские репы, вид в профиль. Просто немного удобнее подключаются и немного удобнее для авторов.
4) Культурные дефолты. Ну там шрифты культурные, особенно в браузерах, оформление гтк2/3 и кутей подогнано друг под друга и система выглядит как система а не визит в зоопарк+кунсткамеру. Все-таки не все хотят быть слесарем допиливающим автотазы до кондиции лишний раз. В дебиане с этим все традиционно плохо.В остальном - да, обычный дебиан, вид в профиль. Просто окультуренный слегонца. Можно ли сделать из дебиана не хуже? Так они это и делают. Значит можно. Просто придется подолбаться самолично. А тут другие за меня подолбались -> PROFIT.
Пока читал, думал что речь о Дебиане.. Хотел даже написать к пункту 1 - что и Убунту недавно перешла на ISO-образы, так же сделали как в дебиане давно работает.. Можно хоть dd-шкой записать на флешку образ, всё равно загрузиться.. А тут речь оказывается наоборот о убунте? ))
Сижу уже эдак года 2 на Wheezy, ещё с ранней альфы, точно не вспомню когда пересел. Помню всего 1-2 случая, которые после обновления что-то было не так.
На тестовом ноуте вообще зоопарк ДЕ у меня, даже из PPA-репозиториев подключены всякие MATE-ы, системы инициализации и прочие свистелки-перделки, и ничё, до сих пор живёт и обновляется без проблем..
Не говоря о убунте, как ни обновление - вечно что-то слетает. И с каждой новой версией, ДЕ всё крепче прибивают гвоздями эдак-как, лижбы-лижбы..
Не.. В плане гибкости и конструктивности, я больше склоняюсь в сторону Дебиан.
Последний дебиан практически не нуждается в допиле.
QT+GTK выглядят нормально.
> флешку образ, всё равно загрузиться..Загрузится. Только образа совмещающего возможность как инсталляции вполне рабочей копии системы так и бута в лив-сессию у дебиана IIRC нет. На выбор или лив-система или инсталл образ. Да еще без нужных мне пакетов (I love XFCE). У убунтуйщиков есть образ из которого мало того что раскатывается вполне съедобная система на основе XFCE, так оно же и в лив может это же загрузить. Так что на все и вся достаточно одной флехи. Это удобно.
> Сижу уже эдак года 2 на Wheezy, ещё с ранней альфы, точно
> не вспомню когда пересел. Помню всего 1-2 случая, которые после обновления
> что-то было не так.Я тоже помню как с вышеупомянутой флехи чинил дебианщикам улетевший в тар-тарары grub, у которого почему-то отвалились модули. Так что система стала совсем unbootable и не починябельна из самой себя.
> На тестовом ноуте вообще зоопарк ДЕ у меня, даже из PPA-репозиториев подключены
> всякие MATE-ы, системы инициализации и прочие свистелки-перделки, и ничё, до сих
> пор живёт и обновляется без проблем..Ну я рад за вас. А мне проще из хубунты выпилить лобзиком то что мне надо.
> Не говоря о убунте, как ни обновление - вечно что-то слетает.
В общем то "обновление" убунты является тупым переключением репов на новые и масс-апдейтом оттуда силами apt-get'а. Такая ракетная наука, конечно...
>И с каждой новой версией, ДЕ всё крепче прибивают гвоздями эдак-как, лижбы-лижбы..Не знаю что там куда прибивают гвоздями. У меня XFCE из xubuntu. Мне он нравится. Но заменяется на что-то еще втыканием 1 метапакета. Если оно вдруг надо.
> Не.. В плане гибкости и конструктивности, я больше склоняюсь в сторону Дебиан.Дебиан неплох как основа для старта какого-то проекта. Ну и для серваков где свежак не надо - нормально. Но на десктопе с ним явно больше возни чем с убунтами при эквивалентном результате.
> Последний дебиан практически не нуждается в допиле. QT+GTK выглядят нормально.Понятия о нормальном у всех разные.
ставить с live iso его можно. но лучше этого не делать (независимо от дистрибутива), а если нужно именно одной кнопкой с минимумом действий - то и ставить убунту (или что-то такое, на массовый десктоп заточенное).
дебиан и убунту это же не конкуренты, по большому счету дистрибутив один и тот же, им выгоднее специализироваться.
а инсталлятор у убунту всегда будет лучше чем у дебиана - там это важно.
> ставить с live iso его можно. но лучше этого не делатьСмотря кому лучше. Мне например проще обкорнать то что будет вкачено убунтой чем самому донапиливать нормальные фонты в браузер и прочая. Ибо ломать - не строить, а в конечном итоге все и так и сяк сведется к apt-get или synaptic, по вкусу. Install это будет или purge - да похрену. При purge еще и время на даунлоад пакетов сэкономится а конечное состояние системы будет такое же. А если нет разницы - зачем долбстись больше? :)
> (независимо от дистрибутива), а если нужно именно одной кнопкой с минимумом действий
> - то и ставить убунту (или что-то такое, на массовый десктоп заточенное).Так вот народ и вопит что мол, не айс, фигли не дебиан и прочая. Ну я и объясняю фигли. Если до них стало уже доходить что 50 сидюков качать - лютейший маразм, я за них только рад.
> дебиан и убунту это же не конкуренты, по большому счету дистрибутив один
> и тот же, им выгоднее специализироваться.Ну дык убунты и специализируются - пытается сделать нормальный user experience. Чего дебиану хронически не хватает. Нет, то-есть при отсутствии альтернатив
> а инсталлятор у убунту всегда будет лучше чем у дебиана - там это важно.
Мне не совсем понятно почему для дебианщиков это не важно, равно как и дефолты после инсталла, которые черти-какие в десктопных окружениях по жизни. Т.е. дубовые контролы в стиле "на дворе win95", шрифты от которых вытекают глаза и прочие прелести. Нет, все это пофиксить _можно_ однако тех кто хочет нормальное авто априори много больше чем тех кто готов стать хардкорным слесарем и выточить некоторые детали для своего авто сам, т.к. на фабрике видите ли "немного накосячили".
Да, плохо когда капот заварен наглухо так что те кто _хотел_ там покопаться такой возможности лишены. Но не сильно лучше и когда все вообще должны стать слесарем энного разряда поголовно, независимо от желания. Я в частности полагаю что если некто взялся собирать софт в дистр - он и дефолты какие-то культурные может и по хорошему даже должен этому софту установить. Иначе это просто вываленный абы как на диск набор софта.
> 1) Вменяемо сделанные лив+инсталл образа. И пишутся что на двд что на флехуВ что курите?!! Или просто неосилятор?
> 2) Нет мучений с древним софтом в дефолтной системе и адовым прыгом
> по граблям после подключения тестинга/анстейбла.Так не делайте этот "адовый прыг". Абсолютно ничего страшного с "древним софтом" нет, если вам надо работать, а не [s]шашечки[/s]версии.
> Может оно менее stable чем stable, но намного лучше чем testing/unstable,
> в которых случается все. Вплоть до факапа GRUB и полного загибания
> системы при ребуте.testing/sid для больших дяденек, не используйте его.
> 3) Есть PPA на случай если охота свежака.
Используйте backports, помимо stable, чтобы поставить реально необходимые версии. Никаких "факапов GRUB" (что бы это ни было), все стабильно работает. Актуальный софт есть.
> 4) Культурные дефолты.
Не берусь судить, все достаточно субъективно. Можете показать на номер бага с данным дефектом?
> В остальном - да, обычный дебиан, вид в профиль.
Думаю, вы просто пока не видели дебиана.
> В что курите?!!Разве что загрузочные образы. У дебиана AFAIK нет образа с которого можно одновременно установить вполне рабочую копию системы + загрузиться с того же носителя в лив сессию. Иметь под рукой более 1 носителя мне неохота а самому компоновать образ который меня устроит - лень, когда оно готовое уже такое есть. А то что там другая лэйба налеплена - да мне похрен.
> Или просто неосилятор?
Кушать кактусы через силу - привилегия НеБыдла и прочих НеДебилов. Ну, тех которым нечем кроме установленной операционки покозырять, etc.
> Так не делайте этот "адовый прыг". Абсолютно ничего страшного с "древним
> софтом" нет, если вам надо работать, а не [s]шашечки[/s]версии.Кроме того что там застарелые баги, зачастую нет нужного функционала и так далее. Алсо у меня довольно мощное и свежее железо которое плохо поддерживается древними ядрами. И даже немолодой GPU и то будет на открытых дровах сильно underpowered на ядрах менее 3.5 - из-за эпик бага с инициализацией многоканального контроллера памяти.
Зачем мне хлам 3+ летней давности когда можно взять намного более свежий софт? Поскольку авторы обычно не враги пользователям - софт, ядра и либы обычно в открытых проектах с течением времени становятся лучше.
>> в которых случается все. Вплоть до факапа GRUB и полного загибания системы при ребуте.
> testing/sid для больших дяденек, не используйте его.Я уже вполне взрослый дяденька. Поэтому мне и не хочется прыгать как школьнику за партой непонятно ради чего.
>> 3) Есть PPA на случай если охота свежака.
> Используйте backports, помимо stable, чтобы поставить реально необходимые версии.Там очень мало и нужного мне как правило не оказывается. И да, мне чертовски удобно когда свежий GCC для ARM и AVR просто вкатывается из репов с вообще нулевым трахом по этому поводу. Да, я могу сам лично билдануть себе кросскомпилер, стань оно реально надо. Но если можно 1 командой его вкатить без этого из дефолтной репы - это отлично, хорошо и правильно. Это то как оно должно работать.
> Никаких "факапов GRUB" (что бы это ни было), все стабильно работает.
> Актуальный софт есть.Опять же, есть некая разница между полутора наименованиями которые забэкпортили и вариантом когда софт не старее полугода в вообще всей репе целиком. Бэкпорт процесс геморный ибо авторы софта не любят некромансить и обычно свежая версия софта зависит от не менее свежих версий либ. И как-то так оказывается что посмотрев на дебиан так и хочется воскликнуть "да тут всю систему менять надо!" (как тот сантехник из анекдота).
>> 4) Культурные дефолты.
> Не берусь судить, все достаточно субъективно. Можете показать на номер бага с данным дефектом?Не могу, ибо не заводил. Простите, хубунта инстальнутая с исохи достаточно близка к тому что мне хочется видеть, в первом приближении. А дебиан в дефолтном виде - явно дальше от этого. Если тех кто это компонует вот в таком виде это устраивает - флаг им в руки и барабан на шею.
>> В остальном - да, обычный дебиан, вид в профиль.
> Думаю, вы просто пока не видели дебиана.Видел, видел. И грабли тех кто им пользуется как десктопом - видел.
>> В что курите?!!
> Разве что загрузочные образы. У дебиана AFAIK нет образаlive.debian.net
>> Так не делайте этот "адовый прыг". Абсолютно ничего страшного с "древним
>> софтом" нет, если вам надо работать, а не [s]шашечки[/s]версии.
> Кроме того что там застарелые баги, зачастую нет нужного функционала и так
> далее.Зато нет и новых багов. А ради функционала можно поставить из бекпортов что-то. То же ядро. Ну не обновлять же каждое приложение?
Старые же баги, если даже исправлений нет в стабильном релизе - они неприменно доступны в виде workarround'ов.
> Зачем мне хлам 3+ летней давности когда можно взять намного более свежий софт?
Ну, например если работать надо, а не тестировать это "свежий софт".
> Поскольку авторы обычно не враги пользователям - софт, ядра и
> либы обычно в открытых проектах с течением времени становятся лучше.Да нет. Все как обычно: релиз => рост багов => стабилизация в последующих выпусках... И цикл заново.
>>> в которых случается все. Вплоть до факапа GRUB и полного загибания системы при ребуте.
>> testing/sid для больших дяденек, не используйте его.
> Я уже вполне взрослый дяденька. Поэтому мне и не хочется прыгать как
> школьнику за партой непонятно ради чего.Скажу иначе: testing/sid для разработчиков и тестеров дистрибутива. Если вы на эту роль не претендуете - пользоваться им не следует.
>>> 3) Есть PPA на случай если охота свежака.
>> Используйте backports, помимо stable, чтобы поставить реально необходимые версии.
> Там очень мало и нужного мне как правило не оказывается. И
> да, мне чертовски удобно когда свежий GCC для ARM и AVRЗАЧЕМ? Вы разработчик gcc? В это слабо верится...
Вот почему наиболее вероятной причиной мне видится зуд в одном месте по поводу версий...
>> Никаких "факапов GRUB" (что бы это ни было), все стабильно работает.
>> Актуальный софт есть.
> Опять же, есть некая разница между полутора наименованиями которые забэкпортили и вариантом
> когда софт не старее полугода в вообще всей репе целиком.Есть разница, конечно. Бекпорты по качеству ближе к stable. А продукты из вашей "вся репа целиком" - разве установятся/удалятся без проблем. И то, не факт.
>>> 4) Культурные дефолты.
>> Не берусь судить, все достаточно субъективно. Можете показать на номер бага с данным дефектом?
> Не могу, ибо не заводил.Ну хоть версия-то какая? Не вижу я этого бага у себя на экране. ЧЯДНТ?
>>> В остальном - да, обычный дебиан, вид в профиль.
>> Думаю, вы просто пока не видели дебиана.
> Видел, видел. И грабли тех кто им пользуется как десктопом - видел.Например?
>> Разве что загрузочные образы. У дебиана AFAIK нет образа
> live.debian.netОтветы "на отвали" не пройдут. Мне "на отвали" не надо, мне чтоб работало. Так как удобно мне. Где у дебиана скачать образ который сочетал бы в себе лив-систему и инсталляху? У них лив-образ IIRC без инсталлера идет. Во всяком случае, когда я качал ливцд дебиана и смотрел на оный (несколько месяцев назад) - было так. Я по-моему доходчиво сказал что мне удобно 1 универсальную флеху на все нужды. Чтобы и лив-сессию с нее (проверка поддержки оборудования для новых машин, репайр поломанных систем, аварийное/портабельное рабочее окружение на пиковый случай) + инсталл системы (если система совсем угроблена, так что проще переустановить чем починить или просто для установки на новый комп).
>> Кроме того что там застарелые баги, зачастую нет нужного функционала и так далее.
> Зато нет и новых багов.Несомненно, но поскольку обычно програмеры все-таки улучшают софт а не портят его - в целом прогресс идет со знаком плюса. Если это не так - такой программой лучше не пользоваться вообще, ибо старую версию майнтанить рано или поздно перестанут и волей-неволей придется чесаться по замене на новую версию. Если там стало хуже - пардон, uninstall.
> А ради функционала можно поставить из бекпортов что-то. То же ядро.
Можно. Но как я уже сказал, там довольно мало софта. И да, мне сильно больше нравится когда софт в десктопной системе максимум полугодичной давности а не трехлетней.
> Ну не обновлять же каждое приложение?
Так я и не обновляю. Воткнул несколько PPAшек с "совсем свежаком" там где это роялило, а остальное и так устраивает, т.к. не сильно архаичное. Полгода - это не три с лишкой все-таки.
> Старые же баги, если даже исправлений нет в стабильном релизе - они
> неприменно доступны в виде workarround'ов.^^^^^^^^^ я вижу баг :P. А с воркэраундами вы и бодайтесь, имхо.
>> Зачем мне хлам 3+ летней давности когда можно взять намного более свежий софт?
> Ну, например если работать надо, а не тестировать это "свежий софт".Ну например, работать в свежем софте как правило приятнее чем в древнем. По багам - примерно паритет. А самые чувствительные баги типа слабых ключей в ssh/ssl - были одинаковы у обоих систем. Рекеить пришлось и тех и других. Wtf is a difference?
> Да нет. Все как обычно: релиз => рост багов => стабилизация
> в последующих выпусках... И цикл заново.Давайте вы не будете меня учить процессу разработки? Плавали - знаем. Получше вашего. И да, у мало-мальски живых проектов за три года упомянутая итерация успевает пройти несколько раз. И все мало-мальски культурные авторы выпускают в релиз именно нечто застабилизированное. Бывают особые случаи, типа ффмпега который никогда не релизился, но он собственно особый как раз тем что его trunk сроду был вполне юзабельным.
> Скажу иначе: testing/sid для разработчиков и тестеров дистрибутива. Если вы на
> эту роль не претендуете - пользоваться им не следует.Ну вот поэтому я и пользуюсь убунтой, т.к. я не против идеи поучаствовать в процессе для некоторых нужных мне программ, однако система мне нужна работающей и без факапов все-таки. А в стэйбле софт слишком некрофильский и меня такой хоккей не устраивает. Более того, новый релиз опять будет некрофильским. Сразу на старте - фаза стабилизации неприлично затянулась, так что версии подтягивать уже перестали, а релиз так и не выкатили до сих пор.
>> Там очень мало и нужного мне как правило не оказывается. И
>> да, мне чертовски удобно когда свежий GCC для ARM и AVR
> ЗАЧЕМ? Вы разработчик gcc? В это слабо верится...Я не разработчик gcc, но зато могу программить под микроконтроллеры с упомянутой архитектурой, например. И чем свежее gcc, тем лучше он генерит код, предупреждает о бОльшем количестве потенциальных проблем, сообщения об ошибках удобнее и так далее. Ну в общем развивается проект. И мыкаться с окаменелой какашкой 3-летней давности или лотереей с бэкпортами - вот уж нафиг.
> Вот почему наиболее вероятной причиной мне видится зуд в одном месте по поводу версий...
Да, зуд, потому что если компилер начинает генерить куда более компактный и/или быстрый код, сообщения об ошибках становятся лучше и компилер ловит больше проблемных ситуаций - это разумно, хорошо и правильно. Зачем мне хренота 3-летней давности если я могу взять свежий gcc 4.7 прямо сейчас?
> Есть разница, конечно. Бекпорты по качеству ближе к stable.
> А продукты из вашей "вся репа целиком" - разве установятся/удалятся без проблем. И то, не факт.Ну как бы если вам удобнее как в дебиане - отлично, я рад за вас. А мне вот удобнее упомянутый подход. Да, он имеет и свои грабли. В том числе и релиз выпуска системы с багами в релизной горячке. Но для меня и моего usage pattern плюсы и профиты перевешивают минусы и риски.
>> Не могу, ибо не заводил.
> Ну хоть версия-то какая? Не вижу я этого бага у себя на экране. ЧЯДНТ?Да любая, 6-й дебиан с установкой гнома2 или XFCE. Если его поставить в более-менее дефолтовом виде - в браузере (файрфокс^W iceweasel) шрифты будут прсто эталоннейшим уг. Особенно русскоязычные. Это вообще беда почти всех линевых дистров, но в дебиане она вылезает особенно люто. Убунты в этом плане выгодно отличаются, утолкав набор очень приличных открытых фонтов. Почему они могут а почти все остальные на это кладут - для меня загадка. Но факт имеет место быть.
>> Видел, видел. И грабли тех кто им пользуется как десктопом - видел.
> Например?Например мыкание с древним софтом или мыкание с глюками системы из тестинга. Вплоть до улета grub нафиг. А упомянутые свойства инсталляционных медий еще и не позволяют удобно хранить одну флеху на все случаи жизни.
>>> Разве что загрузочные образы. У дебиана AFAIK нет образа
>> live.debian.net
> Ответы "на отвали" не пройдут.Ссылочка на главной странице, привожу для самых маленьких:
http://live.debian.net/devel/live-installer/
На стандартных дисках с GUI - на рабочем столе сделана кнопка для установки с образа...А еще там есть конструктор образов, можно и обычный debian-installer включить.
>> А ради функционала можно поставить из бекпортов что-то. То же ядро.
> Можно. Но как я уже сказал, там довольно мало софта.Видимо, кому-как.
> И да, мне сильно больше нравится когда софт в десктопной системе максимум полугодичной
> давности а не трехлетней.Значит, Debian не для вас. Мне нравится, когда все просто работает. С минимум необходимых для этого усилий. На изучение новых кнопочек и изысков дизайнеров интерфейсов каждые полгода - извините, времени нема...
>> Ну не обновлять же каждое приложение?
> Так я и не обновляю. Воткнул несколько PPAшек с "совсем свежаком" там
> где это роялило, а остальное и так устраивает, т.к. не сильно архаичное.И теперь развлекаемся изучением новых кнопок, функций и т.п., вместо работы? ;)
>>> Зачем мне хлам 3+ летней давности когда можно взять намного более свежий софт?
>> Ну, например если работать надо, а не тестировать это "свежий софт".
> Ну например, работать в свежем софте как правило приятнее чем в древнем.Чем "приятно"?
> По багам - примерно паритет.
Ну да? В старый софт все-таки баги не добавляют. А только находят и исправляют.
> А самые чувствительные баги типа слабых
> ключей в ssh/ssl - были одинаковы у обоих систем. Рекеить пришлось
> и тех и других. Wtf is a difference?ubuntu основывается на срезах sid. Учитывая темпы выхода ее релизов - количество дошедших до stable багов будет меньше в разы. Раз в полгода vs раз в два-три года.
>> Скажу иначе: testing/sid для разработчиков и тестеров дистрибутива. Если вы на
>> эту роль не претендуете - пользоваться им не следует.
> Ну вот поэтому я и пользуюсь убунтой, т.к. я не против идеи
> поучаствовать в процессе для некоторых нужных мне программ, однако система мне
> нужна работающей и без факапов все-таки.Могу предположить, что у вас просто очень низкие требования к "работоспособности" системы.
Это в принципе невозможно, в общем случае. "Нужные программы" норовят вытягивать более свежие зависимости, затрагивая все большую и большую часть системы.
Но Debian как раз позволяет делать такие вещи с минимальным риском для системы. Для этого не нужно тупо переходить на тестинг, а нужно использовать apt-pinning и устанавливать новые версии только необходимого ПО.
>>> Там очень мало и нужного мне как правило не оказывается. И
>>> да, мне чертовски удобно когда свежий GCC для ARM и AVR
>> ЗАЧЕМ? Вы разработчик gcc? В это слабо верится...
> Я не разработчик gcc, но зато могу программить под микроконтроллеры с упомянутой
> архитектурой, например. И чем свежее gcc, тем лучше он генерит код,Собирайте уж из trunk тогда, к чему вообще с какими-то пакетами связываться?
>> Есть разница, конечно. Бекпорты по качеству ближе к stable.
>> А продукты из вашей "вся репа целиком" - разве установятся/удалятся без проблем. И то, не факт.
> Ну как бы если вам удобнее как в дебиане - отлично, я
> рад за вас. А мне вот удобнее упомянутый подход. Да, он
> имеет и свои грабли. В том числе и релиз выпуска системы
> с багами в релизной горячке.Ну вот, я таки был прав по поводу ваших требований. Перевешивают видимые вам достоинства "минусы и риски" - не мне судить. Очень может быть, что вы просто обманываете себя. На вашем месте - я бы использовал обычный gcc дистрибутива и собирал бы trunk версию сам.
> Да любая, 6-й дебиан с установкой гнома2 или XFCE. Если его поставить
> в более-менее дефолтовом виде - в браузере (файрфокс^W iceweasel) шрифты будут
> прсто эталоннейшим уг. Особенно русскоязычные.Не вижу, извините.
> Убунты в этом
> плане выгодно отличаются, утолкав набор очень приличных открытых фонтов.Все эти шрифты есть в дебиан. Но не все шрифты из debian есть в убунту (как минимум, в main).
> Например мыкание с древним софтом или мыкание с глюками системы из тестинга.
"Древний софт" сам по себе никакой проблемой не является, вам это объяснили.
> Вплоть до улета grub нафиг.
Тестинг - для тестеров.
> А упомянутые свойства инсталляционных медий еще
> и не позволяют удобно хранить одну флеху на все случаи жизни.А не умеющим читать инструкции - не поможет уже вообще ничто. Это - да, вам на убунту...
> А еще там есть конструктор образов, можно и обычный debian-installer включить.Ой, а можно прямую ссылку для самых-самых маленьких? :) Облазил корень сайта и данную Вами, сходу не заметил. Нагуглился пока только reconstructor.org.
Или Вы про live-build?
>> А еще там есть конструктор образов, можно и обычный debian-installer включить.
> Ой, а можно прямую ссылку для самых-самых маленьких? :)Web Images Builder
http://live-build.debian.net/снизу под "домиком".
> Web Images Builder [...] снизу под "домиком".Надо же, проморгал -- спасибо. Правда, там сейчас "live-build.debian.net CGI building had an outage and is being reconfigured", так что подожду.
> Надо же, проморгал -- спасибо.И я тоже. Что намекает что у дебианщиков с юзабилити не все так гладко как следовало бы. Такие вещи должны быть на самом видном месте. Вот как раз чтобы не возникало таких предъяв. Хотя учитывая что оно в разделе devel, может в этом дело?
>> Надо же, проморгал -- спасибо.
> И я тоже. Что намекает что у дебианщиков с юзабилити не все
> так гладко как следовало бы.Это не официальный проект авторов live-build. Помимо "юзабилити" у "дебианщиков" еще неплохо с головой, почему от работающего live-build, позволяющего собрать себе live-систему очень гибко, они видят на порядок больше пользы, чем от нескольких готовых дубовых live-образов с этой самой странички для загрузки (а-ля бубунту).
> Хотя учитывая что оно в разделе devel, может в этом дело?
Дело в том, что это не актуально, за наличием в дистрибутиве *лучших* альтернатив. Как вам объяснили выше.
Не нужно тупо смотреть "как сделано в убунту". Хоть изредка вы готовы допустить возможность, что можно сдеделать лучше? Здесь как раз тот случай.
> Ссылочка на главной странице, привожу для самых маленьких:
> http://live.debian.net/devel/live-installer/Ах, оно еще и в devel зарыто? Ну извините, если я хочу себе систему которая just works - вы серьезно думаете что я полезу в devel? А вот и фиг, не угадали. Если я не являюсь матерым разработчиком дебиана - фиг с два я в devel полезу. Так, с точки зрения пользователя.
> На стандартных дисках с GUI - на рабочем столе сделана кнопка для установки с образа...
Ну да, я как раз о таком. Только у убунтуев это дефолтный метод распостранения системы. Включая и кубунты, хубунты и прочие лубунты. И все это лежит не где-то сильно сбоку в каком-то девел, а основной образ на самом видном месте. Хотя то что дошло наконец - ну, и то хлеб.
> А еще там есть конструктор образов, можно и обычный debian-installer включить.
Конструкторы образов - это круто, но нишевая штука. Если мне надо 1-2 копии системы, проще вкатить с типовой болванки а потом аптгетом или синаптиком отрихтовать по вкусу. Тем более что типовую болванку можно торентом скачать. И нагрузки сервакам меньше и скорость скачки в канал упирается.
>> Можно. Но как я уже сказал, там довольно мало софта.
> Видимо, кому-как.Ну да, у меня могут быть некие пожелания к софту. И по умолчанию я откровенно предпочитаю свежий софт. Наверное потому что по возможности не закладываюсь на авторов-саботажников портящих новые версии программ. Так что они становятся лучше а не наоборот.
>> И да, мне сильно больше нравится когда софт в десктопной системе максимум полугодичной
>> давности а не трехлетней.
> Значит, Debian не для вас. Мне нравится, когда все просто работает.У меня тоже все просто работает. По крайней мере из того что надо мне. И при том мне не надо мыкаться с доисторическим софтом выпущенном при царе горохе.
> С минимум необходимых для этого усилий. На изучение новых
> кнопочек и изысков дизайнеров интерфейсов каждые полгода - извините, времени нема...Ну знаете, может мне везло, или я предпочитаю софт от адекватных авторов, но этот аспект меня как-то совершенно не напрягает. Намного больше напрягает когда узнаешь что новая версия давно умеет вон то и вот это, что мне как раз и надо было. А тут то болт. Изволь-ка подождать годика три-четыре или долбись с сборкой сам. Или в лучшем случае камикадзь на тестинге/анстейбле. А потом окажется что програмеры не некрофилы и надо libsomething версии не менее чем X+5. А ей надо еще 2 либы. А тем еще пять. Более свежих чем в некрофильской версии системы по дефолту. И понеслась - полсистемы надо заменять. На тестинг или анстейбл. Со всеми вытекающими aka превращением системы в полигон для ядерных испытаний. Ну и тамошнего юзера - в опытного камикадзе, лихо уворачивающегося от очередного п-ца путем умелого лавирования в дебрях опций dpkg.
>> Так я и не обновляю. Воткнул несколько PPAшек с "совсем свежаком" там
>> где это роялило, а остальное и так устраивает, т.к. не сильно архаичное.
> И теперь развлекаемся изучением новых кнопок, функций и т.п., вместо работы? ;)Во первых, я не настолько старый хрыч с заржавелым мозгом чтобы изучение пары опций раз в полгода меня сильно напрягало. Я не утратил способность к обучению и если это улучшит удобство или поднимет эффективность - way to go.
Во вторых, бывают нужные и полезные опции и функции. Если некто допер до некоей опции, есть отличная от нуля вероятность что она придется по вкусу кому-то еще. В том числе и мне. Те кто с этим не согласен - могут юзать наздоровье хоть кернел версии 2.2, мне не жалко.
>> Ну например, работать в свежем софте как правило приятнее чем в древнем.
> Чем "приятно"?Тем что вылечены старые баги и добавлены новые фичи. Например у того же gcc в последних версиях LTO оптимизации еще и юзать стало можно - оно уже не такой рокет сайнс как было раньше и ресурсов жрет в разы меньше. А вы бодайтесь с архаикой. Если оно вам надо.
>> По багам - примерно паритет.
> Ну да? В старый софт все-таки баги не добавляют.Ну так и не фиксят. Бэкпортят только то что касается секурити. А багфиксинг - вот извините.
> А только находят и исправляют.
При бэкпортировании такое IIRC не практикуется. Не говоря уж о добавлени новых фич.
>> и тех и других. Wtf is a difference?
> ubuntu основывается на срезах sid. Учитывая темпы выхода ее релизов -
> количество дошедших до stable багов будет меньше в разы. Раз в полгода vs раз в два-три года.Как я уже сказал, меня tradeoff как в убунтах устраивает больше того чем то что в дебиане. Я в общем случае не готов ждать по три с хреном года каждый релиз подтягивающий софт до актуального состояния проектов (и то - устаревшего, ибо релиз пекли фиг знает сколько).
>> поучаствовать в процессе для некоторых нужных мне программ, однако система мне
>> нужна работающей и без факапов все-таки.
> Могу предположить, что у вас просто очень низкие требования к "работоспособности" системы.Нормальные. ИЧСХ, работает. Если б это было не так - я бы пользовался чем-то еще. В конце концов я сам себе не враг.
> Это в принципе невозможно, в общем случае. "Нужные программы" норовят вытягивать
> более свежие зависимости, затрагивая все большую и большую часть системы.Ну вот поэтому я и поддерживаю идею раз в полгода массово подтянуть все. Заранее распланировав потенциально проблемное мероприятие на тот момент когда потенциальные проблемы ничего не решают. А не постоянно камикадзить на тестинге/анстейбле. И да, как я уже сказал, меня в общем случае нафиг не устраивает софт более чем 3-летней давности. Я не гнушаюсь пользоваться свежим оборудованием, технологиями и фичами - ждать по три года всяких слоупоков я не нанимался. Поэтому с софтом 3-летней давности для меня сплошное мучение. Хочешь повертеть в руках свежую плюшку, а там - болт. Оказывается, полсистемы надо переколбасить. А вот это мне совсем не нравится.
> Но Debian как раз позволяет делать такие вещи с минимальным риском для
> системы. Для этого не нyжно тупо переходить на тестинг, а
> нужно использовать apt-pinning и устанавливать новые версии только необходимого ПО.Можно. Но утомительно. И в результате окажется что один хрен половину системы придется загрейдить. Мне намного проще когда софт будет по дефолту свежий. Потому и убунты...
>>> ЗАЧЕМ? Вы разработчик gcc? В это слабо верится...
>> Я не разработчик gcc, но зато могу программить под микроконтроллеры с упомянутой
>> архитектурой, например. И чем свежее gcc, тем лучше он генерит код,
> Собирайте уж из trunk тогда, к чему вообще с какими-то пакетами связываться?Не, извините, одно дело релиз от апстрима и совсем другое - камикадзинг на свой страх и риск с транком. Понимаете ли, я не хочу собрав программу мыкаться не только с дeбагом своих багов но еще и чужие баги в транковом компилере ловить (вот что-что а транк имеет полное право быть бажным). Не говоря о том что сие куда более затратно по времени. Было время - я билдил себе несколько раз кросскомпилеры сам. А теперь мне чаще всего достаточно просто аптгетнуть. Экономия времени и сил очевидна.
>> имеет и свои грабли. В том числе и релиз выпуска системы с багами в релизной горячке.
> Ну вот, я таки был прав по поводу ваших требований. Перевешивают
> видимые вам достоинства "минусы и риски" - не мне судить.Это обычно в питоновой фигне которую я все-равно выпиливаю первым делом. Типа софтвар центров и single sign-on'ов. Я их глючную питонятину просто пуржу сразу нафиг и забываю о проблеме. А остальное как правило работает и проблем не создает.
> Очень может быть, что вы просто обманываете себя. На вашем месте - я бы
> использовал обычный gcc дистрибутива и собирал бы trunk версию сам.Э нет. Если я пишу программу - это вовсе не значит что в бонус к ее обезглючке я хочу еще и баги компилера выгрeбать в процессе. Если апстрим зарелизил нечто, они полагают что это юзабельно. А если это транк - там что угодно может быть. Это work in progress, со всеми вытекающими. Т.е. не обязано быть сколь-нибудь работоспособным и безглючным в произвольно взятый момент времени. Так что сомнительную привилегию писать программы пользуясь при этом транковой версией компилера я как-нибудь оставлю вам. А сам юзану gcc 4.7.2 с патчами от Linaro который в убунте по дефолту идет. Это и так чуть ли не последняя релизнутая версия gcc. Мне - хватит.
>> прсто эталоннейшим уг. Особенно русскоязычные.
> Не вижу, извините.Ну ой, грузаните дефолтный дебиан и (к,х,л)убунту и сравните.
>> Убунты в этом плане выгодно отличаются, утолкав набор очень приличных открытых фонтов.
> Все эти шрифты есть в дебиан. Но не все шрифты из debian есть в убунту (как минимум, в main).Вот это хз, но почему-то в iceweasel по дефолту русский фонт - просто лютое УГ. Может конечно в каких-то devel версиях этот п...ц починили, конечно, я не проверяю каждый тестовый образ в тщетной надежде на это самое.
>> Например мыкание с древним софтом или мыкание с глюками системы из тестинга.
> "Древний софт" сам по себе никакой проблемой не является, вам это объяснили.А я уже объяснил что я по умолчанию не желаю использовать софт трехлетней давности, который зачастую или не предлагает нужные мне фичи или работает хуже. Если авторы бакланы и в новой версии софт портят а не улучшают - я такой софт вообще обхожу за километр. Все-равно доисторическую версию никто не будет поддерживать бесконечно.
>> Вплоть до улета grub нафиг.
> Тестинг - для тестеров.Спасибо, Капитан.
>> А упомянутые свойства инсталляционных медий еще и не позволяют удобно хранить одну флеху на все случаи жизни.
> А не умеющим читать инструкции - не поможет уже вообще ничто.Инструкции на что? Какие-то devel-версии где-то сильно сбоку? А я разве бил себя пяткой в грудь что я крЮтой разработчик дебиана? Ну или с фига ли я должен лезть глубоко в анатомические особенности devel версий для того чтобы повседневная активность не представляла проблем?
> Это - да, вам на убунту...
Ну так я и юзаю хубунту. Мне из нее сделать то что надо мне как-то просто, понятно и софт там сразу свежий. Без длительного прыга с бубном по граблям.
>> Ссылочка на главной странице, привожу для самых маленьких:
>> http://live.debian.net/devel/live-installer/
> Ах, оно еще и в devel зарыто?"Оно" есть в дистрибутиве. И называется live-build. В общем, все хорошо написано здесь #237.
На ссылку вам указали только потому, что все что вам надо - "хачу как в убунту". В дебиан сделано иначе. На мой взгляд - лучше, причем именно для вашей задачи. Вы вообще допускаете, что можно лучше чем в убунту сделать?
>> На стандартных дисках с GUI - на рабочем столе сделана кнопка для установки с образа...
> Ну да, я как раз о таком. Только у убунтуев это дефолтный
> метод распостранения системы.На вкус и цвет... А пользователи дебиан - предполагаются что не выбирают себе систему методом мышиного тыка.
>> А еще там есть конструктор образов, можно и обычный debian-installer включить.
> Конструкторы образов - это круто, но нишевая штука. Если мне надо 1-2
> копии системы, проще вкатить с типовой болванки а потом аптгетом или
> синаптиком отрихтовать по вкусу.А что мешает сделать это с образом из конструктора? Не говоря уже о том, что не все "аптгетом" потом можно подрихтовать, увы.
> Тем более что типовую болванку можно торентом
> скачать.А пакеты, которые дергает live-build - вообще могут спокойно уже лежать в apt-кэше... Давайте не меряться, ага?
>>> Можно. Но как я уже сказал, там довольно мало софта.
>> Видимо, кому-как.
> Ну да, у меня могут быть некие пожелания к софту.Если вам что-то конкретное нужно - никаких проблем. Открываете баг и получаете от мейнтейнера что пречитается.
> И по умолчанию я откровенно предпочитаю свежий софт.
А вот с бездумным поклонением циферкам в номере версии - вам действительно в Debian делать нечего. Может потом, как подрастете...
> Наверное потому что по возможности
> не закладываюсь на авторов-саботажников портящих новые версии программ. Так что они
> становятся лучше а не наоборот.Гном не так давно - форкнули. Так что все не так радужно даже на таком уровне...
>>> И да, мне сильно больше нравится когда софт в десктопной системе максимум полугодичной
>>> давности а не трехлетней.
>> Значит, Debian не для вас. Мне нравится, когда все просто работает.
> У меня тоже все просто работает.Ну-ну. Вы уж как-то пару раз оговорились, что "иногда"... "бывает"...
> Я не утратил
> способность к обучению и если это улучшит удобство или поднимет эффективность
> - way to go.А если нет? Как обычно и происходит...
Люди с "заржавелым мозгом" еще помнят, что компьютеры предназначены для автоматизации, а не изучения новых кнопочек. Так что "поднимают эффективность", как и прежде - скриптами, обработчиками событий, cron, etc. Плохо, когда все это ломается из-за побитых разработчиком интерфейсов, удаленного "устаревшего" функционала и еще 100500 причин.
>>> Ну например, работать в свежем софте как правило приятнее чем в древнем.
>> Чем "приятно"?
> Тем что вылечены старые баги и добавлены новые фичи.С новыми багами, и? Все в состоянии, полностью аналогичном "древнему софту".
>>> По багам - примерно паритет.
>> Ну да? В старый софт все-таки баги не добавляют.
> Ну так и не фиксят.Фиксят. Сперва узнайте хоть что-то про дебиан, а потом начинайте "критиковать". Смешно, когда "критика" основана на бабушкиных сказках...
> Бэкпортят только то что касается секурити. А
> багфиксинг - вот извините.Не извиняю. Мне стало совершенно очевидно, что с дебиан дела вы не имели. Или давно не имели, по меньшей мере.
> Как я уже сказал, меня tradeoff как в убунтах устраивает больше того
> чем то что в дебиане. Я в общем случае не готов
> ждать по три с хреном года каждый релиз подтягивающий софт до
> актуального состояния проектов (и то - устаревшего, ибо релиз пекли фиг
> знает сколько).Если вам нужен *весь* софт в дистрибутиве в таком состоянии - это клиническое безумие. Установить же конкретные приложения "посвежее" - в дебиан нет проблем, если на такое есть вменяемые и *конкретные* причины.
>>> поучаствовать в процессе для некоторых нужных мне программ, однако система мне
>>> нужна работающей и без факапов все-таки.
>> Могу предположить, что у вас просто очень низкие требования к "работоспособности" системы.
> Нормальные. ИЧСХ, работает. Если б это было не так - я бы
> пользовался чем-то еще. В конце концов я сам себе не враг.Не знаю. Создалось ощущение, что враг. Так бывает, да.
>> Но Debian как раз позволяет делать такие вещи с минимальным риском для
>> системы. Для этого не нyжно тупо переходить на тестинг, а
>> нужно использовать apt-pinning и устанавливать новые версии только необходимого ПО.
> Можно. Но утомительно.Прочитать документацию системы для вас утомительно? Да, вам в убунту...
>> Очень может быть, что вы просто обманываете себя. На вашем месте - я бы
>> использовал обычный gcc дистрибутива и собирал бы trunk версию сам.
> Э нет. Если я пишу программу - это вовсе не значит что
> в бонус к ее обезглючке я хочу еще и баги компилера
> выгрeбать в процессе. Если апстрим зарелизил нечтоКак маленький... Ну собирайте нужные вам ветки, теги из репозитария.
Смысл был в другом: собери сам и поставь рядом с системным компилятором.
>>> прсто эталоннейшим уг. Особенно русскоязычные.
>> Не вижу, извините.
> Ну ой, грузаните дефолтный дебиан и (к,х,л)убунту и сравните.Сравнил. Мне повториться?
>>> А упомянутые свойства инсталляционных медий еще и не позволяют удобно хранить одну флеху на все случаи жизни.
>> А не умеющим читать инструкции - не поможет уже вообще ничто.
> Инструкции на что?apt, dpkg, live-build...
>> Это - да, вам на убунту...
> Ну так я и юзаю хубунту.Ну, чем-бы дите не тешилось...
> Используйте backports, помимо stable, чтобы поставить реально необходимые версии. Никаких
> "факапов GRUB" (что бы это ни было), все стабильно работает.
> Актуальный софт есть.Найдите там Postgis 1 для Postgresql 9.1 x 64
>> Используйте backports, помимо stable, чтобы поставить реально необходимые версии. Никаких
>> "факапов GRUB" (что бы это ни было), все стабильно работает.
>> Актуальный софт есть.
> Найдите там Postgis 1 для Postgresql 9.1 x 64Значит, настолько актуально, не в обиду вам...
1.5.2 - есть в backports. С поддержкой pg 9.1 - есть в wheezy. Попросите, могут добавить.
> Вменяемо сделанные лив+инсталл образапару лет уже и в дебиане есть. Да позже чем в убунте, но не сильно.
http://www.debian.org/distrib/
Образы для дисков и флешек, лайв образы, разные DE, загрузка http,ftp,torrent все давно есть.
> Нет мучений с древним софтом
Тестинг в зубы и вперед. Бекпорты и секурити репозитарии вообще мало кто осиливает, ибо чукча не читатель, чукча писатель.
Тестинг как он есть (http://wiki.debian.org/DebianTesting):Packages from Debian Unstable enter the next-stable testing distribution automatically, when a list of requirements is fulfilled:
The package has been in "unstable" at least for 2-10 days (depending on the urgency of the upload).
The package has been built for all the architectures which the present version in testing was built for.
Installing the package into testing will not make the distribution more uninstallable.
The package does not introduce new release critical bugs.> Есть PPA на случай если охота свежака
И это человек еще что-то говорит про тестинг =)
> Культурные дефолты
Это бред. Гном он и в африке гном. КДЕ, etc. тоже.
> Ну там шрифты культурные
Ага, а еще в убунте горизонт не завален.
> пару лет уже и в дебиане есть. Да позже чем в убунте, но не сильно.
> http://www.debian.org/distrib/И где там гибридный образ который был бы одновременно инсталл-диском и лив-образом? Там почему-то лив образ отдельно а инсталл - отдельно. Мне не нравится идея складировать горку флешек с образами. Удобно когда одна флеха - на все лады.
> Образы для дисков и флешек, лайв образы, разные DE, загрузка http,ftp,torrent все давно есть.
Только образа все-в-одном нету. А у убунтуев - есть и сватается по дефолту. И мне это удобно, между прочим.
>> Нет мучений с древним софтом
> Тестинг в зубы и вперед.Спасибо, я видел чем это заканчивается. Мне рабочая система зачастую нужна. И ее отказ может мне икаться.
> Бекпорты и секурити репозитарии вообще мало кто осиливает, ибо чукча не
> читатель, чукча писатель. Тестинг как он есть (http://wiki.debian.org/DebianTesting):Нет, я не сомневаюсь что как следует по@#$вшись как-то юзать можно и дебиан. Но с убунтой этого побочного и нежелательного процесса - как-то сильно меньше. Там вообще искаропки софт нормальный. И если в тестинге могут все переколбасить в любой момент, то в убунтах между выпусками софт в репах никто не трогает и если уж он есть - значит есть и не отвалится.
> The package does not introduce new release critical bugs.
Ага, я заметил. Как у некоторых дебианщиков аж GRUB отъезжал. До unbootable. Не, спасиб, мне зачастую работающая система нужна а не ядерный полигон. А полигон я хочу устраивать лишь в том объеме который мне удобен. То-есть я не против вкатить пару альфабетатранкверсий какой-то софтины являющейся объектом внимания. Но для всего софта вообще - увольте.
>> Есть PPA на случай если охота свежака
> И это человек еще что-то говорит про тестинг =)Да, ибо прыгинг по граблям с 1-2 программами ради какой-то конкретной фичи или чего-то еще позарез сдавшегося мне - это ок. Тут я и багов напишу, и кунг-фу применю по полной, и вообще, авторы могут рассчитывать на компетентную работу над решением проблемы, ибо в моих интересах не меньше чем в их. А вот со всей системой так прыгать - нифига не ок.
>> Культурные дефолты
> Это бред. Гном он и в африке гном. КДЕ, etc. тоже.А вот тема оформления в дебиане не фонтан. И подгонкой вида gtk2, 3 и кути там никто не заморачивается. Нехай сам юзер долбется причесывая этот зоопарк.
>> Ну там шрифты культурные
> Ага, а еще в убунте горизонт не завален.Шрифты - дрянь. В браузере на русскоязычный фонт там вообще без слез смотреть нельзя. В номинации "отстойные фонты в браузере" дебиан наверное вообще лидер среди дистров. Настолько эталонный вырвиглаз не переплюнул имхо вообще ни 1 дистр.
>И где там гибридный образ который был бы одновременно инсталл-диском и лив-образом? Там почему-то лив образ отдельно а инсталл - отдельно. Мне не нравится идея складировать горку флешек с образами. Удобно когда одна флеха - на все лады.чукча не читатель, чукча писатель?
>Теперь вы можете попробовать Debian, загрузив живую систему с CD, DVD или USB носителя без установки файлов на ваш компьютер. Когда вы будете готовы, вы можете запустить содержащийся там установщик
> Когда вы будете готовы, вы можете запустить содержащийся там установщикО, они это все-таки наконец сделали? И что, даже для XFCE есть образ содержащий все пакетики? Если не врете - ну ок, претензия снимается. Просто я не так давно как раз вертел в лапах образ с live debian с их сайта но никаких инсталлеров я там не припоминаю.
> 1) Вменяемо сделанные лив+инсталл образа. И пишутся что на двд что на
> флеху, и можно как установить систему так и просто загрузиться в
> лив-сессию на посмотреть/починить/оценить поддержку железа в полном объеме/запасной
> парашют на случай внезапных факапов. У дебианщиков формат распостранения довольно
> ушибленный.JFYI, если включить в рассмотрение UEFI -- то хуже ubuntu-12.10 свежего релиза ещё не видел. Возможно, надо было взять ещё какой-то другой образ, но *никакими* штатными описанными средствами загрузить это в EFI mode мне не удалось.
хз недавно пробовал ubuntu-12.10 и грузится и устанавливается на uefi, также нормально и 12.04 работал
> JFYI, если включить в рассмотрение UEFI... то удастся ли на оном загрузить релизный дебиан вообще, пардон? Благо 6-я версия вышла фиг знает когда. Ну, я надеюсь что вы не предлагаете всем вокруг прыгать по граблям с предрелизными версиями?
> но *никакими* штатными описанными средствами загрузить это в EFI mode мне не удалось.
А еще бывают клоуны хардкодящие в UEFI фирмвару названия загрузчиков для полутора операционок (типа винды и рхел). Так навскидку попался какой-то образ uefi биоса, который я распатронил. От души подивился: там какие-то циркачи натурально захардкодили название загрузчика. Во дебилы! Defective by design.
...по поводу чего я как-то так купил себе новое мощное железо с классическим биосом которого мне надолго хватит. Он до кучи умеет и UEFI-boot, но насколько оно работает - я не проверял. Т.к. не испытываю желания узнавать о ж@порукости биосописателей лишний раз. И если в классическом биос им было сложно фатально накосячить то вот в UEFI - это очень даже можно.
>> JFYI, если включить в рассмотрение UEFI
> ... то удастся ли на оном загрузить релизный дебиан вообще, пардон?Релизный -- вроде как нет, а вот беты грузятся (но не совсем благополучно инсталятся).
> Ну, я надеюсь что вы не предлагаете всем вокруг прыгать по граблям с предрелизными
> версиями?Скажем так -- чинить *релизную* убунту я не взялся. Штатно рекомендуемые бубны проверил, да. Не помогают.
>> но *никакими* штатными описанными средствами загрузить это в EFI mode мне не удалось.
> А еще бывают клоуны хардкодящие в UEFI фирмвару названия загрузчиков для полутора
> операционок (типа винды и рхел).Не тот случай, сузя и мои поделки инсталируются нормально. Собсно можно и в virtualbox попроверять, просто там не так видно, что не грузится и не собирается (особенно до 4.2).
> Релизный -- вроде как нет, а вот беты грузятся (но не совсем благополучно инсталятся).Да, теперь у трактора заводится мотор. Только при попытке пахать - начинает увязать. Сомнительное счастье в случае когда задача - "вспахать".
> Скажем так -- чинить *релизную* убунту я не взялся. Штатно рекомендуемые бубны
> проверил, да. Не помогают.К счастью пока машины с UEFI не сильно распостранены, так что проблема не то чтобы злободневна. А как станут распостраненными - так и отпадет как раз. Злободневные проблемы - долго не живут.
>> А еще бывают клоуны хардкодящие в UEFI фирмвару названия загрузчиков для полутора операционок (типа винды и рхел).
> Не тот случай, сузя и мои поделки инсталируются нормально.Ну, я рад за них. Впрочем для меня это полезно как для зайца стопсигнал.
> Собсно можно и в virtualbox попроверять, просто там не так видно, что не
> грузится и не собирается (особенно до 4.2).Ну вот пусть кому не терпится в это вляпаться и разгребают свои грабли. Пораскинув мозгами лично я пришел к выводу что не сильно хочу вляпываться в то чего пытаются сделать из x86 платформы интель и майкрософт.
>> 1) Вменяемо сделанные лив+инсталл образа. И пишутся что на двд что на
>> флеху, и можно как установить систему так и просто загрузиться в
>> лив-сессию на посмотреть/починить/оценить поддержку железа в полном объеме/запасной
>> парашют на случай внезапных факапов. У дебианщиков формат распостранения довольно
>> ушибленный.
> JFYI, если включить в рассмотрение UEFI -- то хуже ubuntu-12.10 свежего релиза
> ещё не видел. Возможно, надо было взять ещё какой-то другой
> образ, но *никакими* штатными описанными средствами загрузить это в EFI mode
> мне не удалось.т. е. загрузчик поломан в релизе? или не поддерживает нужной фичи?
просто загрузчик много кто ломал недавно (даже opensuse умудрились).
> т. е. загрузчик поломан в релизе? или не поддерживает нужной фичи?Не диагностировал уже.
> просто загрузчик много кто ломал недавно (даже opensuse умудрились).
У них как раз заработало (12.2 встала в EFI mode безупречно).
> Вплоть до факапа GRUB и полного загибания системы при ребуте.Давеча как раз убунту обновлял. Не загрузилась после обновления. Надпись на экране "grub>" и всё. Ну и ещё какой-то текст сверху.
А не подскажете какие именно пакеты выпиливаете? Я б тоже выпилил.
> А не подскажете какие именно пакеты выпиливаете? Я б тоже выпилил.Все что касается убунту single sign-on, софтвар центра, крашрепортинга (падающий при репортинге краша крашрепортер - пи...ц в духе докторватсона, товарищи!), тормозного и глючного апдейтера на питоне висяшего в трее и донимающего анонсами и тому подобную нафигнужную околохомячковую требуху.
Да, это отрубает некоторый "хомячковый" функционал + я не смогу поставить коммерческий софт из софтцентра (а оно мне надо?). Мне этот функционал и не уперся: я программы ставлю аптгетом или синаптиком и оным же выполняю апдейты (а если надо автоматом - крон). Да и вообще, у меня хубунта, ибо юнити - нафиг надо.
Т.е. я по сути рассматриваю убунты как всего лишь удачный набор репов и инсталляционно-ливцдшную медию с удачными дефолтами. И таки да, настолько брутальное махание бензопилой^W аптгетом/синаптиком требует понимания что вы выпиливаете и нафига, как и понимания что есть метапакет, чем чревато его удаление (при апгрейде версий систем может икнуться). Я не жуже Canonical знаю что мне надо. Просто мне проще выпилить лишнее из их системы чем затолкать нужное в том же дебиане, например.
Безбашенно повторять эти фокусы не рекомендуется, если что. Я всегда проверяю что намерен сделать пакетиный менеджер и понимаю что будет в результате. Безбашенное повторение чревато всем чем угодно вплоть до unbootable системы.
Спасибо, это и так было выпилено сразу.
Главное это :
export UBUNTU_MENUPROXY=0
export LIBOVERLAY_SCROLLBAR=0
или удаление оного, вот это действительно свистелочки, которые замедляют систему и под fluxbox совсем не нужные...
> Спасибо, это и так было выпилено сразу.Ну еще можно выпнуть всякие там недо-плееры понимающие полтора формата, но это уже эстетство. Ну и да, я выпинываю в том числе и зависимости питонятины типа python-twisted и какой там еще требухи. Которая по лично моему мнению - явно лишний элемент моей системы.
Мы не про питон, мы про sh
И потом Ubuntu - не показатель.
bash скрипты выполняются медленней в основном не за счет самого факта интерпретации, а за счет того, что вместо вызовов функций часто вызываются внешние программы. Затраты на их запуск и IPC и замедляют баш.
Угу. Только там на тысячу вызовов доли секунды уходят. Что не значимо ни при каких сценариях кроме самых экзотических
> bash скрипты выполняются медленней в основном не за счет самого факта интерпретации,
> а за счет того, что вместо вызовов функций часто вызываются внешние
> программы. Затраты на их запуск и IPC и замедляют баш.А вы хоть раз заглядывали в сами скрипты? Я вот только что просмотрел один из самых толстых, который отвечает за инициализацию сети. Так вот, там внешних программ аж две штуки, остальное всякие if, eval и т. п.
И, да, я лучше доверю конфигурацию системы внешним программам, которые вылизывались годами, чем чей-то очередной поделке, которая неизвестно как тестировалась, и неизвестно как себя поведет если шаг вправо - шаг влево.
В дебиане из коробки используется не bash, а dash. Он легче и быстрее.
> В дебиане из коробки используется не bash, а dash. Он легче и
> быстрее.По сравнению с парсером конфигов и одиночным fork/exec - не намного.
Очень актуально. Что ж, один, и основной, аргумент любителей systemd отсечён окончательно. Кроме того, теперь можно не доказывать то, что этого преимущества нет, а просто давать ссылку на эту новость.
Какой это - основной? Скорость? Он далеко не основной.
Уже нет?
Он им и не был. А вот почему хейтеры на нем внимание заостряют постоянно, я не знаю, наверно по той же причине. по которой не понимают его сути. Все, кто пробовал systemd (а их уже очень много) давно поняли, что не так уж заметно он быстрее грузится.
+ а остальные, как не пробовали, так и не собираются, делая свои выводы о systemd лишь по отзывам бабок на базаре.
остальным и пробовать не надо, если стоит ssd загрузка происходит за 16с максимум, или ребут не чаще раз в месяц чтобы ядро перестановить. Какой смысл пробовать? Скорость тут вообще не показатель, fsck дольше делается.
> остальным и пробовать не надо, если стоит ssd загрузка происходит за 16сO_O нифига себе вы его тормознули. У меня более 5 секунд не занимает. В обычной убунте.
написал максимум поэтому, вообще не засекал но чай налить не успеваю.
Когда я говорю о том, что скорость - не основное достоинство systemd, ты мне говоришь о том, что тебя твоя устраивает, поэтому systemd тебе ненужен. Какая замечательная логика. Xейтеpы такие xейтеpы...
Так залогиньтесь, если говорите, все понимают что скорость это не единственный недостаток systemd
Во-первых, не надо говорить за меня.
Во-вторых, не обязательно разбираться в сортах г-на, что бы понять, что оно несъедобно.
Во-третьих, если заявления автора продукта для вас "отзыв бабки на базаре", то о чём с вами вообще можно говорить.
Потому что всё остальное, выдаваемое за преимущества, на поверку оказывается недостатками во многих ситуациях. Впрочем, после того, как я увидел исходники localed и hostnamed из состава systemd я серьёзно об ЭТОМ разговаривать вообще не намерен. Ибо сделано дегенератом.
>сделано Леннартом (хотя по ходу одно и то же, лол) ^_^очевидный фикс
> Впрочем, после того, как я увидел исходники localed
> и hostnamed из состава systemd я серьёзно об ЭТОМ разговаривать вообще не намерен.Это вы не видели еще как оно учило писать библиотеки. Где-то валялся отдельный прожект с шаблоном "как надо делать" (тм).
Деточка, качество кода и качество его работы - вещи не всегда взаимосвязанные. И я уверен, у Поттеринга опыта в программировании побольше твоего будет.
> качество кода и качество его работы - вещи не всегда взаимосвязанные.Всегда. И чем дольше проект живет, тем показательнее будет эффект говнокода на качестве работы. Даже если оный говнокод всеми силами стараются переписать.
> И я уверен, у Поттеринга опыта в программировании побольше твоего будет.
Откуда у вас такая уверенность, в отношение незнакомого человека?
> Всегда.Чушь. Порой за определенное время код пишется так, чтобы решал на определенный период времени определенный круг задач. После этого он считается устаревшим, выбрасывается и пишется новый.
Особенно часто этот прием используется в сложных инструментах, которые с первого раза правильно не пишутся. Systemd к ним относится как раз. Это еще довольно молодой проект.
Как видишь, не всегда.
>> Всегда.
> Чушь. Порой за определенное время код пишется так, чтобы решал на определенный
> период времени определенный круг задач. После этого он считается устаревшим, выбрасывается
> и пишется новый.Простите, мы о проектах, которые люди другим показывают, а не о кронтабах васи-админа, гда >/dev/null 2>&1 в конце и логика "скрипт запускается - значит работает".
> Особенно часто этот прием используется в сложных инструментах, которые с первого раза
> правильно не пишутся. Systemd к ним относится как раз.Чего? Это такая порнография предлагается вами для системных приложений? Да для них - архитектура до недавнего времени была на первом месте. А если спроектировано приложение правильно - нет никаких оправданий написанию говнокода, кроме кривизны рук.
> Простите, мы о проектах, которые люди другим показывают, а не о кронтабах васи-админа, гда >/dev/null 2>&1 в конце и логика "скрипт запускается - значит работает".Отвыкай воспринимать open source как шоу-бизнес. Конечная программа есть конечная программа, а не игра на публику.
> Чего?
Внутренняя архитектура никакого отношения к внешнему апи не имеет. Корче, хватит нести чушь.
>> Простите, мы о проектах, которые люди другим показывают, а не о кронтабах васи-админа, гда >/dev/null 2>&1 в конце и логика "скрипт запускается - значит работает".
> Отвыкай воспринимать open source как шоу-бизнес. Конечная программа есть конечная программа,
> а не игра на публику.Не игра, да. Но умные люди стараются не выставлять себя на посмешище всему свету.
Так что разница между тяп-ляп скриптами "для дома, для семьи и себя любимого" и настоящими проектами - есть и большая.
> Внутренняя архитектура ... к внешнему апи ...
"Лоровец", нахватавшийся вумных слов?
>> Простите, мы о проектах, которые люди другим показывают
> Отвыкай воспринимать open source как шоу-бизнес.Показывать != делать шоу.
> Внутренняя архитектура никакого отношения к внешнему апи не имеет.
> Корче, хватит нести чушь.Поговорили с умным человеком -- вот и славненько, а теперь спокойной ночи, Бонапарт и архитектор.
> Поговорили с умным человеком -- вот и славненько, а теперь спокойной ночи, Бонапарт и архитектор.Ты всегда так реагируешь на умные слова? И главное - возразить нечего. А ведь так хочется, правда? Вот и приходится ерничать.
> Ты всегда так реагируешь на умные слова?Видите ли, их в Вашем сообщении не было. А по сказанным заметно, что не имеете ни малейшего представления ни об архитектурном процессе, ни о том, что и как "в open source" (и в частности -- какое психологическое значение имеет доступность создаваемого кода).
>Особенно часто этот прием используется в сложных инструментах, которые с первого раза >правильно не пишутся. Systemd к ним относится как раз. Это еще довольно молодой проект.С Леннардом своё мнение согласовал? Он пишет, что продакшн-реди и уже все дистры перешли на системд кроме Убунту. А ты внезапно: "молодой проект", "код выкидывать и писать новый".
Качество кода там нормальное. Там с архитектурой (головоногого мозга Поттеринга) беда. Когда для операции, которая выполняется после первичной установки системы примерно никогда делается отдельынй демон, который единственное, что делает - это принимает сообщение по D-Bus и читает или пишет стандартный файл - это уже о многом говорит. Но когда я вижу, что оно даёт возможность подписаться на изменения этой настройки, при этом не пытаясь через fanotify ловить изменения самого файла чем-то сторонним - я понимаю, что systemd целенаправленно делали так, чтобы навязать его использование.
Тьфу, головного мозга, конечно. Но, однако, привет Фрейду.
Ну, есть еще такая штука, как преждевременная оптимизация, которая вредна. Не стоит этого исключать. Через пару лет посмотрим во что превратится этот модуль, сейчас судить о качестве кода рано - вдруг по его задумке это просто прототип. Хотя, если не терпится, можешь посмотреть на PulseAudio, в последнее время его неплохо так подтянули, стал совсем не то что был года 2-3 назад.В данном случае я не защищаю Поттеринга, но нападки на него считаю во многом необоснованными.
Ну скажите, кто и когда в здравом уме будет менять дефолтную локаль, да ещё так, чтобы это надо было подхватить тут же. И чтобы это делал не администратор в конфиге, а нужно было именно по D-Bus? У меня фантазии не хватает. Отсноительно хостнейма - то же самое. Но если уж у них хватает фантазии предположить, что какой-то софт может быть подписан на такие события, не обработанный простейший случай с правкой конфига руками - очень хороший маркер.
Чтото я Ленарта только в контрибуторах PulseAudio не вижу.
Дык напакостил и свалил.
> Очень актуально. Что ж, один, и основной, аргумент любителей systemd отсечён окончательно.
> Кроме того, теперь можно не доказывать то, что этого преимущества нет,
> а просто давать ссылку на эту новость.А какое время должен был показать системд, чтоб "основной аргумент" не был отсечён? Минус 3 секунды? Загрузиться до нажатия кнопки запуска?
>> Очень актуально. Что ж, один, и основной, аргумент любителей systemd отсечён окончательно.
>> Кроме того, теперь можно не доказывать то, что этого преимущества нет,
>> а просто давать ссылку на эту новость.
> А какое время должен был показать системд, чтоб "основной аргумент" не был
> отсечён? Минус 3 секунды? Загрузиться до нажатия кнопки запуска?Это вопрос не по адресу, это надо автора спросить. А то он как-то отвлекся от первоочередной задачи в сторону написания сопутствующего софта, наполовину заменяющего операционную систему.
В общем случае, "заметно быстрее" - это величина заметная на глаз, обычно устанавливается в 20%. Но это не значит, что для решения задачи "приходить на работу вовремя" надо переделать весь мир вокруг: снести жилые районы и построить шоссе, купить самую быструю машину, отменить правила дорожного движения и запретить смену времен года. Если заместо всего этого можно просто вставать с кровати раньше.
Уважаю людей, который способны на глаз заметить разницу между 3 и 2.5 секундами.
> Уважаю людей, который способны на глаз заметить разницу между 3 и 2.5 секундами.Пардон, это на вшивой виртуалочке. На реальном железе поболее будет.
Уж сколько раз твердили миру... что скорость загрузки - вообще не аргумент кроме очень специальных ситуаций (эмбед всякий), где вообще лучше свой костыль ваять.
> Очень актуально. Что ж, один, и основной, аргумент любителей systemd отсечён окончательно.
> Кроме того, теперь можно не доказывать то, что этого преимущества нет,
> а просто давать ссылку на эту новость.Основное преимущество systemd - это его прозрачность и простота конфигурирования, особенно по сравнению с upstart и sysvinit. Можно не доказывать, что он есть, а просто предлагать создать/настроить конфиг/скрипт для какой-нибудь службы.
> по сравнению с upstart и sysvinit. Можно не доказывать, что он
> есть, а просто предлагать создать/настроить конфиг/скрипт для какой-нибудь службы.Пардон, в апстарте настройка не сложнее будет. А может и проще. С sysvinit - да, простынка на экран текста будет выглядеть жутковато.
> Пардон, в апстарте настройка не сложнее будет. А может и проще. С
> sysvinit - да, простынка на экран текста будет выглядеть жутковато.Проще, проще. Организация конфигов и возможность управления симлинками в systemd очень неплохо продуманы. А таргеты гораздо гибче ранлевелов.
Те же симлинки и ранлевелы, что в sysvinit, только в профиль.
> Проще, проще. Организация конфигов и возможность управления симлинками в systemd очень
> неплохо продуманы. А таргеты гораздо гибче ранлевелов.Пилять, в апстарте нет никаких ранлевелов. Там только эвенты. А ранлевелы эмулируются эвентами. Ну, возникает событие "обана, наступил ранлевел такой-то". И если надо - пинаются инит-скрипты классического инита по этому поводу. Через добавочные приспособы которые по этому эвенту делают то же что и инит (отдельный пакетик - совместимость с инитом). Если конечно такие скрипты есть. Так обеспечивается совместимость с старьем. Да, некоей ценой снижения скорости в этом месте. Зато старье ничего не знающее о эвентах вообще не подозревает что это был не sysvinit и работает без бубна и напильника как и раньше. А по мере желания народ пишет джоб-файлы, оперируя более гибкими эвентами и зависимостями. Неспешно и без отвалов башки. Плавно мигрируюя систему без шума и пыли. Этот момент перцы из каноникала продумали очень здраво.
Но да, я в одном соглашусь: написать джоб апстарту намного проще и приятнее чем портянки для sysvinit. Это же и про systemd можно сказать. Вот что-что а портянки где логика перемешана с конфигурационными значениями в одно непотребное месиво - это ужас, да.
> Вот что-что а портянки где логика перемешана с конфигурационными значениями
> в одно непотребное месиво - это ужас, да.Вот что-что, а если конфигурационные значения выносить в /etc/default, не будет непотребного.
> Вот что-что, а если конфигурационные значения выносить в /etc/default, не будет непотребного.Сферические кони в вакууме - это круто. А реальные скрипты попадающиеся в тех или иных программах - оставляют желать много лучшего. Мне что, все эти простынки на страницу текста самому чтоли переписывать? Да нафиг надо, в этом плане в пять раз проще юнит апстарту написать.
> А таргеты гораздо гибче ранлевелов.Очередной оратор не в курсе, что гибкость и простота обычно по разные стороны качелей -- вот с собой и дискутирует, того не замечая...
позвольте - что сложного в настройке нескольких переменных в файле?
А теперь сраните с написанием оного в С коде.
> позвольте - что сложного в настройке нескольких переменных в файле?
> А теперь сраните с написанием оного в С коде.Что баш, что си править - монопенисуально. Конфиги гораздо проще.
И утыкаться в пределы гибкости конфигов. Либо делать вагон параметров, который будет не запоминаем в принципе.
Там сейчас и есть вагон параметров. Те кто хвалят systemd за "простоту", по моему, ничего нетривиального сделать не пытались.
Я об этом и говорю.
> Те кто хвалят systemd за "простоту", по моему, ничего нетривиального сделать не пытались.Кстати, у них очередной прекрасный шанс не популизмом позаниматься, а делом доказать: http://lists.altlinux.org/pipermail/devel/2012-November/1959...
> И утыкаться в пределы гибкости конфигов.А вот там пусть уже и вступает в игру баш. Или си. Или там что кому нравится.
Вот только мне совершенно не улыбается тырить с стройки компрессор и пневмомолот для того чтобы 1 мелкий гвоздик забить. Если мне надо запустить мелкий типовой сервис, виноватый только тем что для него никто не написал портянку на баше или написал такое уродище что лучше не писали бы совсем - вот нафига там дергать интерпретер на почти мег и портянку на экран?
>вот нафига там дергать интерпретер на почти мегЭто судя по всему вы /bin/bash померили ))) спасибо я поржал
>портянку на экранчем вам так shell страшен, консоль не разу не открывали
самая тривиальная вещь
Перезагрузка конфигов nginx, как мне её в systemd сделать
Запустить то я могу таким скриптом а дальше что?[Unit]
Description=The nginx HTTP and reverse proxy server
After=syslog.target
After=network.target
After=mysql.service
After=phpfpm.service[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true[Install]
WantedBy=multi-user.target
О! Вот если б так позиционировали и реализовывали - шуму было бы меньше: "обрабатываем десятком параметров простые случаи, которых 80%, а для остального есть sh". А у них (systemd) over-engineering по всем фронтам - от моего любимого примера с localed и до попыток всё упихать в параметры. Бинарный лог с http-сервером - из той же серии.Впрочем, у параметров есть одно нехорошее свойство. Если что-то не так с шелл-скриптом - разобраться можно с разумными усилиями. А если как-то не так воспринимается параметр - надо лезть в исходники systemd (которые ещё где-то взять надо, нужной версии) и выяснять, как же он там понимается. Что там в апстарте по этому поводу - не знаю, но в systemd процесс очень непрозрачный, и лога вида "теперь делаем x, потому что A,b и с" от него не дождёшься, как и какой-либо интроспекции.
> О! Вот если б так позиционировали и реализовывалиТак эти опции никто в таких системах и не отбирал. Если можно выполнять программы - очевидно, таковой может выступить и шелл-интерпретер с скриптом. Я почему-то думал что это доступная даже детсадовцу логика, но оказывается - нифига подобного.
>> О! Вот если б так позиционировали и реализовывали
> Так эти опции никто в таких системах и не отбирал. Если можно
> выполнять программы - очевидно, таковой может выступить и шелл-интерпретер с скриптом.
> Я почему-то думал что это доступная даже детсадовцу логика, но оказывается
> - нифига подобного.Вы второе предложение дочитайте.
> Вы второе предложение дочитайте.Дочитал. Знаете, непрозрачных портянок на баше писаных ж@порукими бабуинами я тоже видел достаточно, это похуже либого сорса на си от поттеринга или кого там еще. Там еще и конфигурация с кодом перемешана. Прикольно по всему скрипту параметры вылавливать. Даже очень. А если самому с нуля писать - джоб апстарту я явно быстрее накатаю в типовом случае.
> особенно
> по сравнению с upstart и sysvinit. Можно не доказывать, что он
> есть, а просто предлагать создать/настроить конфиг/скрипт для какой-нибудь службы.А не особенно по сравнению с чем? Прямо интересно стало.
upstart практически идентичен по производительности systemd и теперь можно не доказывать "что он", быстрый systemd "есть", а давать ссылку на новость что upstart не хуже?
У вас проблемы с логикой.
Поделитесь опытом, в каком месте systemd прозрачный?
> Поделитесь опытом, в каком месте systemd прозрачный?Говорят что если распечатать сорц и просветить распечатку рентгеном - достаточно прозрачно получается.
>его прозрачность и простота конфигурированияМожно пример такой прозрачности? Я вот в /etc/systemd только что заглянул и ничего там не понял.
> Можно пример такой прозрачности? Я вот в /etc/systemd только что заглянул и ничего там не понял.А я посмотрел в шеллскрипты для запуска psybnc и проверки живости по крону и вволю поблевал. Плюнул и написал джоб апстарту за три минуты вместо килограмма феерических костылей на баше который там был. И что характерно, функционал остался тот же. Зато уместилось в 5 строчек конфига. Включая перенастройку приоритета (так оригинал не умел даже) и какой-никакой минимальный мониторинг живости сервиса (намного лучше чем дефолтовая горбизна на баше с проверкой раз в 5 минут по крону с помощью костылей и подпорочек).
собака лает, караван идет...Ну надо же, разработчик убунту попробовал доказать, что стартер убунту не так плох как системд, и "смог!" . В следующей новости прочитаем, как Леннарт доказывает очередным выходом системд-ххх, что уж системд то лучше всех и теперь в нем есть плюшки YYY . Далее традиционное "разработчики upstart портировали плюшку YYY в апстарт, провели тесты по три раза, и теперь апстарт не хуже системд". И при выходе каждой новости "сисемд хейтеры" VS "апстарт/убунту-хейтеры" срут кирпичами, "окончательно отсекают" и т.д. и т.п.
и это все в разделе "Главные новости"... Максим, откройте раздел отдельный "Срач хейтеров", оставьте новости новостями.
>В следующей новости прочитаем, как Леннарт доказывает очередным выходом системд-ххх, что уж системд то лучше всех и теперь в нем есть плюшки YYYВ переводе еще упустили момент из оригинальной новости:
I also noticed that having systemd installed would slow down booting with other init systems, because systemd installs udev rules which take a noticeable amount of time to run a helper command at boot even though the helper should be a no-op. So if you're doing boot speed testing of other init systems, be sure you don't have systemd on the system at the time!
То есть детище Поттеринга через udev уже наложило кучу конкурентам. Так сказать, превентивный акт возмездия :)
из-за этого и половина срачей, есдиб udev отдельно шел то всем было бы пофиг на systemd.
как бы это почти идеальный вариант развития ситуации. Вполне возможно, что в апстарте не будут повторять ошибки systemd
> как бы это почти идеальный вариант развития ситуации. Вполне возможно, что в апстарте не будут повторять ошибки systemdБудут-будут. Все уже убедились, что у них ума хватает только копипастить.
> Будут-будут. Все уже убедились, что у них ума хватает только копипастить.Если мне не изменяет склероз, то upstart постарше systemd будет. Это справедливости ради.
> Будут-будут. Все уже убедились, что у них ума хватает только копипастить.А как они выпустили свой апстарт на 4 года раньше? Ведь копипастить было не с чего! :)
>> Будут-будут. Все уже убедились, что у них ума хватает только копипастить.
> А как они выпустили свой апстарт на 4 года раньше? Ведь копипастить
> было не с чего! :)Потом пришёл Юзер и порвал анонимам шаблон.
> собака лает, караван идет...собака поёт, караван танцует :D
>> собака лает, караван идет...
> собака поёт, караван танцует :DИндийское кино?
RHEL в будущем перейдёт на systemd. Надеюсь, Debian и Ubuntu последуют этому примеру.
Очень надеюсь, на обратное - что не последуют!
Надейся.
> Надейся.От надейся слышу.
> Очень надеюсь, на обратное - что не последуют!Ubuntu - точно не перейдет, космонавт хочет поломать своместимость с линуксом.
Debian - зависит от того, прогнутся ли под космонавта. Хотя, если не прогнутся, могут остаться на sysvinit (тоже достойный выбор).
> Ubuntu - точно не перейдет, космонавт хочет поломать своместимость с линуксом.Космонавт просто не хочет лизать всяким поттерингам за просто сам факт их существования. А кто изгибается под все прихоти красношапки - в общем то ничего из себя не представляющие лузеры. Ну и место на рынке они займут соответствующее. Ибо лузеры не способные контролировать свой вектор развития рынку нахрен не нyжны.
Какой вообще идиот решил, что systemd == linux?
автор. // КО
> Какой вообще идиот решил, что systemd == linux?Пототеринг :)
Сферические показатели в вакууме. Где может себя показать распараллеливание при загрузке базовой системы, практически без демонов?
> Сферические показатели в вакууме. Где может себя показать распараллеливание при загрузке базовой системы, практически без демонов?Что поделать, это единственный расклад, при котором Upstart сливает не очень позорно. Если надобавлять демонов на уровне обычного сервака, слив upstart будет очевиден.
> Если надобавлять демонов на уровне обычного сервака, слив upstart будет очевиден.И грузить на реальном железе. Рубка - так уж по полной, без скидок. Пусть рубаются.
>> Если надобавлять демонов на уровне обычного сервака, слив upstart будет очевиден.
> И грузить на реальном железе. Рубка - так уж по полной, без скидок.Еще один "знаток" систем виртуализации и VM в linux, или все тот же?
> Еще один "знаток" систем виртуализации и VM в linux, или все тот же?Тот же, тот же. Заметьте, даже в виртуалочках и systemd и upstart уделали классический инит. Что ожидаемо. На реальной системе обычно все несколько хуже т.к. там больше операций связанных с оборудованием и прочая. На реальной железке может быть несколько сетевок, пачка дисков которые надо монтировать и прочая. На виртуалках так обычно не делают.
>> Еще один "знаток" систем виртуализации и VM в linux, или все тот же?
> Тот же, тот же. Заметьте, даже в виртуалочках и systemd и upstart
> уделали классический инит. Что ожидаемо.Разница в секунду (и меньше) - это (мягко говоря) весьма далеко от "уделали".
Мне это вот что напоминает, не обижайтесь:
http://www.youtube.com/watch?v=UMuRvAbLO-8
> Разница в секунду (и меньше) - это (мягко говоря) весьма далеко от "уделали".С учетом того что это минмальная виртуалка а не железная машина с кучей сервисов - сойдет. Хотя лучше было бы на реальной машине с кучей оборудования и прочая. Где 100500 лишних пинков немаленького интерпретера отольется по полной.
И да, замечу что с классическим инитом ряд вещей которые в апстарте или системд делаются парой строк конфига на баше можно и по граблям попрыгать.
> Сферические показатели в вакууме. Где может себя показать распараллеливание при загрузке
> базовой системы, практически без демонов?В штатном дебиановском sysvinit _тоже есть_ распараллеливание. Еще со времен squeeze.
>> Сферические показатели в вакууме. Где может себя показать распараллеливание при загрузке
>> базовой системы, практически без демонов?
> В штатном дебиановском sysvinit _тоже есть_ распараллеливание. Еще со времен squeeze.Вот и протестировали бы его во всех трёх.
> Вот и протестировали бы его во всех трёх.А его никто и не отключал, судя по всему.
>> Вот и протестировали бы его во всех трёх.
> А его никто и не отключал, судя по всему.Да, его просто не использовали, поскольку сравнили для простейшего случая, в котором возможностей sysvinit хватает с головой.
Попробуйте читать новость внимательно:
Загрузка с классической системой инициализации Sysvinit и _со штатными дополнениями для распараллеливания запуска сервисов Startpar_ была выполнена за 3.37 сек.
> Попробуйте читать новость внимательно:
> Загрузка с классической системой инициализации Sysvinit и _со штатными дополнениями для
> распараллеливания запуска сервисов Startpar_ была выполнена за 3.37 сек.Вы невнимательно прочли мой комментарий. Я говорю не о том, что в sysvinit распараллеливания нет. Я говорю о том, что тестирование было поставлено таким образом, что никакие фичи сложнее базовых попросту не использовались. Ну нет при загрузке базовой системы ничего настолько существенного, чтоб можно было увидеть разницу, скажем, в реализации распараллеливания во всех трёх. Что можно распараллелить при запуске полутора демонов? Какой можно получить выигрыш от предварительного создания сокетов для них? Тестирование ниочём.
Вот ваша цитата
>Да, его просто не использовалиЕго использовали. Если вы имели ввиду, что от использования не было проку, то так и надо было писать. Внимательное чтение и телепатия это разные вещи. Ну и кроме того, демонов там куда больше трех, что можно посмотреть из графиков bootchart в статье, также как и сколько из них запускалось одновременно. Учитесь читать новости и ясно выражать свои мысли.
Так распараллеливание умеют все, а сунь туда пару-тройку крупных демонов (которые, понятно, запускаются долго) - и все различия уйдут на уровень погрешности.
> запускаются долго) - и все различия уйдут на уровень погрешности.Зато писать конфиги тому же апстарту не в пример быстрее и приятнее чем распихивать по нескольким местам простыни на шелскрипте.
Это где так мрачно? Если есть возможность - гляньте, как оно в Дебиане - скрипты простейшие, настройки для них ложатся в одноимённые файлы в /etc/conf.d - и никаких проблем нет. Клянусь, дело 3-х минут для простого демона набросать скрипт запуска.
> Клянусь, дело 3-х минут для простого демона набросать скрипт запуска.Его и "набрасывать" не надо. Готовый к копипасту код лежит в
/usr/share/debhelper/dh_make/debian/init.d.ex
Сменить пару переменных окружения, скорректировать зависимости сервиса - и на этом все.
в /etc/init.d/skeleton всё что надо есть, это я в генту глянул, они такой скелет не дают, нужно какой-то из существующих копировать.
> в /etc/init.d/skeleton всё что надо естькстати, да - там тоже есть. Это тот же самый файл, почти буквально.
Тьфу, ошибся - глянул в консоль с Гентой, в которой обычно и сижу. Впрочем, в дебиане не сложнее - скопировал /etc/init.d/skeleton во что нужно, поправил в его первых строках переменные окружения, если надо - подкрутил зависимости. Те же три минуты.
>В Debian Unstable добавлена система инициализации UpstartUpstart в Debian с 2006 года есть.
>>В Debian Unstable добавлена система инициализации Upstart
> Upstart в Debian с 2006 года есть.Туда добавили _новый_ upstart 1.6.3. И сравнили с systemd годичной давности (v44).
Вот это я понимаю - бенчмарк. Гражданиеу myhand на заметку.
Что Стиву уже можно в qemu, а мне нельзя?
> Что Стиву уже можно в qemu, а мне нельзя?Он по крайней мере сравнил все 3 системы в более-менее одинаковых условиях. Да, сферических и в вакууме. Но - одинаковых.
>> Что Стиву уже можно в qemu, а мне нельзя?
> Он по крайней мере сравнил все 3 системы в более-менее одинаковых условиях.Ну так кто вам запретил привести цифры для systemd? Конфигурацию вам описали - вперед.
Моей целью не было сравнение. Я ответил systemd-фанбою, который утверждал что стандартный инит не сумеет преодолеть планку в 5секунд. Причем привел в качестве примера не только образ с qemu...
> стандартный инит не сумеет преодолеть планку в 5секунд.Сильно от конфигурации зависит. Не, если вам нравится писать портянки на страницу, которые к тому же запускаются медленнее - флаг вам в руки и барабан на шею. А мне с апстартом как-то явно проще оказалось. Ну то-есть я сначала костылил скрипты как все. А потом не поленился читануть ман на апстарт и гуглануть пример. Теперь для меня добавление типового сервиса в систему стало намного проще и приятнее. Плюс мониторинг отвала сервиса минимальный есть. Голыми руками, за 5 минут. Ловкость рук и никакого обмана.
>> стандартный инит не сумеет преодолеть планку в 5секунд.
> Сильно от конфигурации зависит.Да не очень, на самом деле. Редкий сервер грузится дольше.
Просто какие-то дистрибутивы потрудились реализовать параллельный старт сервисов на обычном sysvinit, а какие-то ждут чуда (upstart, systemd), вместо того чтобы обновить свою античную систему скриптов. Вот пользователи таких дистрибутивов и фантазируют принципиальные проблемы sysvinit, учитывая только свой опыт.
> Плюс мониторинг отвала сервиса минимальный есть. Голыми руками, за 5 минут.
Ничего. Подрастете - догадаетесь выключить и использовать инструменты, соответствующие задаче.
>> Сильно от конфигурации зависит.
> Да не очень, на самом деле. Редкий сервер грузится дольше.Чем 3 секунды? Ну разве что если у него системным диском SSD. И у сервера оборудования намного больше, да и файловых систем и прочая - тоже.
> sysvinit, а какие-то ждут чуда (upstart, systemd), вместо того чтобы обновить
> свою античную систему скриптов. Вот пользователи таких дистрибутивов и фантазируют
> принципиальные проблемы sysvinit, учитывая только свой опыт.Ну вот если то что раньше требовало портянки на экран теперь влезает в 5 строк конфига - мне так удобнее. А если конфига не хватит вдруг для какой-то совсем хитрой хрени - вот тогда я оттуда и позову уже скрипт. Только это будет не в 100% случаев а допустим в 5% случаев. А в остальных 95% будет в несколько раз меньше геморроя -> PROFIT.
>> Плюс мониторинг отвала сервиса минимальный есть. Голыми руками, за 5 минут.
> Ничего. Подрастете - догадаетесь выключить и использовать инструменты, соответствующие задаче.Оставьте ваше менторство себе. У меня все работает и довольно неплохо. At the end of day это единственное что реально всех интересует. А у меня к тому же минимум геморроя. И теперь мне не надо переть ынтырпрайзные средства для пары мелких фиговин, колупаться по куче мест в разных закоулках и прочая. Я склонен это приветствовать.
> Вот это я понимаю - бенчмарк. Гражданиеу myhand на заметку.А ты вообще кто? Что сделал?
> А ты вообще кто? Что сделал?Я ваш тезка. И немного потроллил, имея на то некие причиы.
Вроде бы это было очевидно? Значит я еще и Капитан к тому же :)
>> А ты вообще кто?
> Я ваш тезка.Не, он явно не 294-й. :)
> Основной причиной большого расхождения между systemd и upstart стало наличие unit-файла для запуска rsyslog, в то время как для upstart не было подготовлено соответствующего job-файла. После удаления unit-файла для rsyslog время загрузки с systemd увеличилось до 2.78-3.03 сек.Все правильно сделал - не добавил job-файл (потому что это ничего бы не дало), а удалил service-файл. Потому что сокет-активация, дававшая существенное ускорение запуска, в upstart не поддерживается.
> Все правильно сделал - не добавил job-файл (потому что это ничего бы не дало),Почеу же? Это сэкономило бы дерг жирного интерпретера и парсинг оным огромной простыни. А вот взлетит процесс по сокет-активации или какому-то иному критерию - до балды скорее всего.
>> Все правильно сделал - не добавил job-файл (потому что это ничего бы не дало),
> Почеу же? Это сэкономило бы дерг жирного интерпретера и парсинг оным огромной
> простыни.Upstart тоже дергает жирный интерпретатор на каждый job.
А от сокет-активации _одной_ службы - выигрыш 30% времени.
> Upstart тоже дергает жирный интерпретатор на каждый job.
> А от сокет-активации _одной_ службы - выигрыш 30% времени.Прям на каждый, прям ТАКОЙ жирный. Куда деваться.
У системж значит одни плюсы, минусов нет. Да?Или ты только плюсы изучал? Или за другими повторяешь?
> Upstart тоже дергает жирный интерпретатор на каждый job.Чего бы это ради на каждый? Это просто конфиг-файлы, не являющиеся сами по себе шеллскриптом. Да, там можно оттуда и скрипты пинать, но это уже вопрос номер два.
> А от сокет-активации _одной_ службы - выигрыш 30% времени.
И, конечно же, вы поделитесь данными профайлинга и бутчартами доказывающими этот тезис? Или вы предлагаете поверить вам на слово, как гражданин myhand?
Прекрасная новость!Это то, чего как раз не хватало, а не хватало объективного сравнения.
Надо только теперь на этом не останавливаться и подготовить тесты на разных типах железа, и отдельно тестирование для типичного сервера (большое количество сетевых сервисов и старт СУБД до кучи)
Кроме того, очень хотелось бы объективно оценить стабильность работы основного функционала для всех трех менеджеров применительно к сильно нагруженным сетевым сервисам. Допустим, к nginx при >4000 подключений.
> Прекрасная новость!
> Это то, чего как раз не хватало, а не хватало объективного сравнения.Сравнение примерно настолько же объективное, как и http://www.0pointer.de/blog/projects/why
Лангашек стремится всюду пропихнуть upstart, и поэтому люто ненавидит systemd. И в тестах он порядочно намухлевал (чего только стоит удаление сокета для rsyslog).
Тогда тем более нужно объективное сравнение.
> Тогда тем более нужно объективное сравнение.Нужно-то нужно, да только кто его сделает? Каждый кулик будет свое болото хвалить.
Ну, не все так плохо, как кажется. Есть авторитетные издания которые могут и постараться для своих читателей, есть производители серьезного тяжелого софта, которые кровно заинтересованны в стабильности эксплуатации своего ПО и т. д.Главное, что бы до этого дошло дело, и что бы появился реальный выбор.
> Главное, что бы до этого дошло дело, и что бы появился реальный выбор.Реального выбора нет и не будет. Поддержка системы инициализации (любой) требует сильного переколбашивания базовых механизмов дистра. Поэтому тянуть даже два инита, и даже если один поддерживает совместимость с другим - очень трудно. Например, опенсуся и арч не смогли.
А три-четыре - вообще анриал.Sysvinit уже не жилец, это очевидно. Вот поэтому федора, убунта и гента и сошлись в великой битве - кто же из них присунет свой инит всем дистрам.
> Например, опенсуся и арч не смогли.Так они не зря в лузе находятся. Невнятные поделия без собственного вектора развития.
>> Например, опенсуся и арч не смогли.
> Так они не зря в лузе находятся. Невнятные поделия без собственного вектора развития.Водился в Киевском университете проф. Плахотник, читавший у нас математику. И рассказывал он как-то, хитро поглаживая усы, как в советские времена математически доказал, что генеральная линия политики партии подозрительна на перегиб в каждой точке, вследствие чего имел беседу с особистом. А доказательство было простое: согласно решениям такого-то пленума ЦК, генеральная линия политики партии -- прямая; если взять вторую производную линейной функции, то в каждой точке она будет равна нулю, а ведь равенство второй производной нулю является необходимым условием экстремума!
Это к чему вспомнилось: разумеется, "вектор" развития той же федоры или, чего уж там, the linux kernel -- он того, много где подозрителен. Одни VM-перипетии в 2.4/2.6 или вот метания по инитам чего стоят.
Но ведь Вы правда расскажете о чём-то железобетонно внятном и с непременно своим, а заодно разумным, вектором развития? А то ещё и у истоков стояли?..
> Но ведь Вы правда расскажете о чём-то железобетонно внятном и с непременно
> своим, а заодно разумным, вектором развития? А то ещё и у истоков стояли?..Я всего лишь пытался намекнуть что если некто хапает то что вывалила шапка вообще не разбираясь надо ли это им - они напоминают китайцев тупо клонирующих 1 в 1 брендовый шмот.
Насчет конкретно systemd, тут все хитро. С одной стороны было бы хорошо если бы все пришли к общему знаменателю. С другой стороны, сотрудничек редхат отличился тем же чем обычно, т.е. звездной болезнью, некооперативностью и низкой степенью адекватности. Теперь народ будет форкать у себя внутрях дистра не только glibc но и systemd? :) Докатиться до того чтобы обвинить убунту в фрагментации - совсем уж неадекват. Даже вы признаете что апстарт написан раньше.
Грубо говоря, если допустить что мне приперло бы делать свой дистр, я бы не стал systemd юзать, пожалуй. Даже не потому что технические дефекты. А потому что такой апстрим - это головняк на всю голову и заявка на уйму проблем в будущем.
> Даже вы признаете что апстарт написан раньше.Брр, а чего тут признавать? Как помню, так и пишу.
Лучше голову включить и сравнивать не только время решения конкретной задачи, но и проблемы которые создаются при решении этой задачи.
Думаю, интересные результаты показало бы подобное сравнение на машине с флоппи-дисководом и одним из сервисов, опрашивающим этот дисковод. Можно заменить флоп на компакт-дисковод со вставленным диском, тоже вариант.
По мотивам "Папа, покажи, какая у тебя система многозадачная!"
какая разница вообще сколько система загружается? что это за системы такие которые часто ребутятся? кто вообще сказал что время загрузки системы - критический показатель ? может быть все же для системы инициализации важнее то на сколько её удобно админить?
Ну, например, роутер без бесперебойника позволяет оценить прелесть быстро загружающейся системы.
Это, конечно, простейший бытовой вариант.
В роутере systemd )))) Без комментариев
вот роутер — http://www.mitxpc.com/proddetail.asp?prod=EKJAD5254LM350. теперь разрешаете воткнуть туда systemd?
Sorry, this product is not currently available. Разрешаю )))
в d-link dir-320 воткни если втыкалка не сломается
> вот роутер — http://www.mitxpc.com/proddetail.asp?prod=EKJAD5254LM350. теперь
> разрешаете воткнуть туда systemd?Всего за 300 баксов? Ох черт, а в ближайшем ларьке на 300 баксов можно целый мешок роутеров купить.
> В роутере systemd )))) Без комментариевГента в роутере - еще круче.
Я как-то спрашивал буржуев про принципиальную необходимость быстрой загрузки, приводя им в пример ноутбуки, которые не выключаются, а спят, сервера, которые не выключаются в принципе, и рабочие станции, которые включаются один раз в день, при приходе на работу.Знаете, что мне ответили, причём несколько человек? "Ну дык эта, венду-то ведь часто надо загружать". Аргумент американских Ъ-линуксоидов, ога. Других ответов не было.
за 3.37 сек ? не может быть
Вполне, на мощном железе, + SSD и т.п.
Что и требовалось доказать. Точнее и так было видно для того кто реально сравнивал разные системы инициализации.
Вспоминается: http://www.youtube.com/watch?v=NVLTEq3BZQ0
> Интеграция Upstart дала возможность проведения сравнительной оценки скорости загрузки
> дистрибутива при помощи Upstart, базовой системы инициализации sysvinit, а также доступной
> в репозиториях системой загрузки на базе systemd.
> теперь стало возможным выполнить комплексную оценку скорости работы трёх указанных системО чём Стив и написал: тестируйте, мол, теперь можно, а я, мол, сделал только первую простейшую прикидку на "пустой" системе без сервисов в qemu.
> После проведения тестирования
Где? Не-не-не, Дэвид Блэйн.
> сделал только первую простейшую прикидку на "пустой" системе без сервисов в
> qemu.exim, rsyslog, udev, dhclient, etc - это уже не сервисы? Там их под десяток наберется.
>> сделал только первую простейшую прикидку на "пустой" системе без сервисов в
>> qemu.
> exim, rsyslog, udev, dhclient, etc - это уже не сервисы? Там
> их под десяток наберется.Это был перевод по памяти и впечатлению. Ты прав.
""I'm not aware of anyone having done a real, fair comparison[...]I've done some initial comparisons in a barebones sid VM
>> сделал только первую простейшую прикидку на "пустой" системе без сервисов в
>> qemu.
> exim, rsyslog, udev, dhclient, etc - это уже не сервисы? Там
> их под десяток наберется.Они все лёгкие. Нужно большие, тяжёлые, активно читающие диск и проводящие всякие проверки целостности. postgres, mysql с innodb, redis, mongo.
Не сервисы. Потому что для реальной жизни интересует ситуация, когда сервисов много, они запускаются долго и сильно нагружают систему. Вот тогда есть смысл смотреть, что как себя ведёт. А здесь - хоть две секунды, хоть пять - роли это не играет ни малейшей. если б у него там хотя бы Jira какая или там Openfire или мускуль с хорошей базой, который сразу начинали бы запросами пинать и он лез бы к диску активно - это да, было бы интересно. На худой конец - хотя бы запуск KDE или Gnome (там, по идее, часть их запуска может идти параллельно с догрузкой системных сервисов).
> проведённого тестирования можно отметить: использование эмулятора QEMU, вместо реального оборудованияНа виртуальной машине - нечестно! Конь-шар в вакууме.
Хочу тесты на реальном железе, с реальными задержками и т.д.
Тогда и скажу какая система инициализация будет в моём следующем дистре! )А вобще пусть соревнуются, пусть вылизывают код - нам же лучше.
И OpenRC туда до кучи
Да пусть добавляют хоть BSD-style, лишь бы SysV не выпиливали!
> И OpenRC туда до кучиАноним открывает для себя Гугль, фильм I: Озарение. http://lmgtfy.com/?q=debian+openrc
К чему тесты на скорость загрузки системы, которая применяется в основном на серверах. Уж лучше бы сравнивали надежность, функциональность, маштабируемость и простоту настройки систем. Это имеет смысл для серверного решения. Скорость нужна при ловле блох, а здесь не тот случай.
Вот людям делать нечего, сравнивают скорость загрузки. Да какая разница, сколько времени система грузится? Для десктопов и ноутов это пох -- всё равно из hibernate все поднимаются, там пох на систему инициализации. Для серверов тоже пох из-за тормозных RAID-контроллеров, да и не выключает их никто.Почему бы не сравнить удобство управления сервисами в дальнейшем, когда уже всё работает? Ну и последствия от сбоя системных служб :-)
> Вот людям делать нечего, сравнивают скорость загрузки.Это люди, которые разрабатывают эти самые "системы загрузки".
_Им_ надо! Надо же как-то оправдываться. Да, остальным поthing.
> Да какая разница, сколько времени система грузится?
Столько возни из ничего... Поставьте себе Arch и будет вам полный systemd. У меня ноут-1.7 ГГц+SSD и то видно что скорость загрузки выше. А нонешней убунте на нем вообще делать нечего. Преимущество Arch очевидно - не надо супер платформу для того чтобы иметь самое новое ПО. (PS ядро 3.6.7)
> Преимущество Arch очевидноВ сравнении с убунтой по выбранному критерию скорее очевиден недостаток убунты, а вот _преимущество_ было бы заметней на ~128..256M. :)
А зачем вам самое новое ПО? И зачем вам загрузка за 5с вместо 10с? Вы только не подумайте что я пытаюсь вас троллить. Просто интересен изкейс для чего это нужно?
>Из недостатков проведённого тестирования можно отметить: использование эмулятора QEMU, вместо реального оборудования; измерение скорости загрузки до приглашения shell без учёта времени запуска реального десктоп-окружения и серверных служб; использование для анализа устаревшей версии утилиты bootchart, предоставляющей менее детальную информацию о процессе загрузки; сравнение свежей версии Upstart (1.6) с systemd годичной давности (v44).ну и на кой черт тогда вообще все это выкладывать? в толксы!