Телепатия и экстрасенсорика существует. Я как раз собирался создавать тред о целесообразности перехода с Kubuntu на Debian c KDE. Интересуют подводные камни вроде видеодров и прочей проприетарщины для игорей. Также интересно: быстрей ли? Много разговоров о прожорливости и неповоротливости каноничной. Ну и стабильность же: за 4 года убунтоводства никаких серьёзных проблем не имел, не будет ли их при дебиановодстве?
Понятия не имею. Сломали они это сто лет назад, с тех пор и не работает, хотя как минимум три последних версии убунты я не проверял, но вряд ли что-то поменялось.
Да раньше (Ubuntu 10.04, Debian 6) и второгном убунтовскй проигрывал по скорости дэбиановскому;-) И уже тогда убунта была глюкодромом по сравнению с дэбианом. Вечно что-то падало. Руки кривые? Debian почему-то прощал!
The and and or operators allowed with start on and stop on do not work intuitively: operands to the right of either operator are only evaluated once and state information is then discarded. This can lead to jobs with complex start on or stop on conditions not behaving as expected when restarted. For example, if a job encodes the following condition:
start on A and (B or C)
When 'A' and 'B' become true, the condition is satisfied so the job will be run. However, if the job ends and subsequently 'A' and 'C' become true, the job will not be re-run even though the condtion is satisfied. Avoid using complex conditions with jobs which need to be restarted.
«фатальный недостаток», если хорошо поискать, можно найти в чём угодно, но каков шанс в это вляпаться? Я профессионально работаю с ubuntu server с версии 8.04, вероятность вляпаться стремится к нулю.
Этот «фатальный недостаток» — всего лишь пример того, что там есть чему ломаться.
Я из своего опыта помню, что когда этот апстарт только впилили, сначала было «вау, крутая штука, загружает систему за 15 секунд» (причём там даже не столько upstart ускорял, сколько ureadahead). Но каждый раз после установки убунты через месяц использования и регулярных обновлений это говно начинало загружать систему по полторы минуты. И это при том, что никаких его настроек я даже не пытался менять. Может, сейчас он и загружает систему, я давно не пробовал, но в сравнении с systemd он мне всё равно нравится значительно меньше:
Апстарт просто запускает процессы при наступлении событий (и то, как я уже выше процитировал, даже с этим не справляется). Systemd не просто запускает демоны, а и следит за ними.
В последнее время upstart стал просто массово переносить в себя фичи из systemd. Так зачем мне пользоваться ещё недоделанным апстартом, в который ещё не все фичи systemd успели перенести, если можно просто взять systemd?
С задних рядов мне сейчас подсказывают, что ppa:kubuntu-ppa/next содержат разработчики KDE и, по совместительству, мейнтейнеры из Ubuntu: https://launchpad.net/kubuntu-packaging-next/ topcontributors . Jonathan Riddell, к примеру в Blue Systems работает. Если уж эти люди не знают как правильно собрать Кеды, то это, видимо, должно быть адовое DE.
Подтверждаю, использую Kubuntu c 2007г., каких-то серьёзных дистроспецифичных проблем нет, кроме мелких багов самих кед, о которых репортят и пользователи других дистров. А вот баги в кедах фиксят очень медленно, если они не критичные (т.е. практически забивают, особенно если в багтрекере за них мало голосуют). Недавно Мартин Граблин позакрывал мои багрепорты, висевшие там больше года по причине того что четвёрка больше не пилится :D
А тех кто форсирует стереотипы о том что в Kubuntu якобы кеды кривее чем в других дистрах, следует банить.
Но каждый раз после установки убунты через месяц использования
Хронический вендузятник.
Я не переставлял текущую десктопную Кубунту с 2009г., например.
это говно начинало загружать систему по полторы минуты.
А выяснить с помощью bootchart в чём проблема у хронического вендузятника ума не хватило, конечно же.
Апстарт просто запускает процессы при наступлении событий (и то, как я уже выше процитировал, даже с этим не справляется). Systemd не просто запускает демоны, а и следит за ними.
Не ври, upstart именно что следит за демонами и в случае их завершения эмитирует соответствующее событие, которое позволяет другим демонам отреагировать соответствующе, если у них в конфиге указано соответствующее правило для этого события (типа stop on stopped job_name). Upstart также поддерживает respawn, позволяющий автоматически перезапускать упавший демон. И всё это было уже давно.
В последнее время upstart стал просто массово переносить в себя фичи из systemd.
убунту это вообще странный дистриб, у меня федора 21 когда была в бэте а не в релизе и то меньше багов имела, я до сих пор помню смех когда при обновлении системы их утилитой для обнов был кэрнел паник...
Поддержу. Причем когда как - если ее поставть и не трогать, то и полет нормальный будет относительно. Если же попытаться что-то сделать - то последствия непредсказуемы. Например, в последний раз у меня после обновления просто упала - после загрузки я видел тупо черный экран иксов и все, юнити не стартовало. Дело вроде бы было в дровах на видяху, но черт его знает. Особенно обидно было, потому что именно в этот момент мне кровь из носу нужен было компьютер.
15,04 уже в бете, и там ядро более тухлое чем в федоре 21.
Вот за несколько лет на Линуксе так и не увидел, чем распоследняя версия ядра так принципиальна для десктопа того самого простого пользователя. Что из этого http://www.opennet.ru/opennews/art.shtml?num=41712 списка меня может заинтересовать на десктопе?
Я переустанавливал её каждый раз не из-за того, что вендузятник, просто я часто менял дистрибутив :D
А выяснить с помощью bootchart в чём проблема у хронического вендузятника ума не хватило, конечно же.
Мне сложно сейчас что-то сказать, потому что той убунты уже нет несколько лет. То, что я помню, — это сообщение «Waiting up to 60 more seconds for network configuration», которое, как я тогда выяснил, не имеет никакого отношения к ожиданию конфигурации сети, а возникало из-за какого-то другого ожидания во время sysinit. Что именно там было — уже не помню.
upstart именно что следит за демонами и в случае их завершения эмитирует соответствующее событие
Это отслеживание завершения демона, а не слежка за демонами. Не знаю, как сейчас, но когда я пользовался апстартом, там поддержки cgroups не было и в помине, стало быть, апстарт даже не мог уследить за процессами, которые были запущены в результате работы демона.
KDE пользуются либо бездельники, у которых слишком много свободного времени, либо мазохисты, которым нравится, когда компьютер их унижает. Для работы оно непригодно. Поэтому в любом дистрибутиве от выбора KDE эффект одинаковый — убить время, получить боль и и просто почувствовать себя дегенератом («когда собаке делать нечего, она яйца лижет» - народная мудрость).
А обосновать хейтерство не судьба? Трындеть — не мешки ворочать. Лично я никаких заметных недостатков в кедах, окромя некоторой прожорливости, не вижу.
В чём преимущество ubuntu server перед Debian (ну, кроме фиксированных релизов, конечно)?
В корпоративной среде наличие такой штуки как lts позволяет довольно точно планировать жизненный цикл решений и стоимость их владения.
Это понятно. Так вот я и говорю, что на этом все преимущества ubuntu server по сути и заканчиваются. Тем более что Debian перешёл на systemd, и Ubuntu вслед за ним, отказавшись от своего upstart. И да, в Debian ввели практику LTS релизов.
А обосновать хейтерство не судьба? Трындеть — не мешки ворочать. Лично я никаких заметных недостатков в кедах, окромя некоторой прожорливости, не вижу.
Да и так все очевидно и, по большому счету, не стоит обоснования, но раз просишь:
требует минимум в два раза больше компьютерных ресурсов, чем любое другое известное окружение рабочего стола;
существует в замкнутой экосистеме, выход за пределы которой также требует дополнительных накладных расходов (пример - установить приложение КДЕ в другой среде значит установить гигабайт ненужных для всего остального библиотек), причем отдельная экосистема создается целенаправленно - с точки здравого смысла понять это невозможно;
из-за собственной экосистемы КДЕ практически ничего не дает в общую копилку приложений свободного десктопа;
набор программ и их качество внутри этой экосистемы не обеспечивают нормальную полноценную работу пользователя;
до недавнего времени использовался проприетарный набор для разработки;
на маломощных компьютерах просто не стартует;
случаи падения КДЕ случаются в несколько (десятков -?) раз чаще, чем у других окружений рабочего стола;
плазма до сих падает;
разработчики сконцентрированы на экспериментах (обкатывают идеи, которые потом внедряет микрософт - ?), а не на потребностях пользователей (классический пример - семантический десктоп);
абсолютно вырвиглазный неудобный дизайн - эспериментальная суть распространяется и сюда;
склонность к бесконечному количеству настроек, значительная часть из которых не работает;
ну и главное - оно просто плохо, очень плохо работает и никто, кому надо использовать компьютер для создания чего-то, использовать эту кривую дурноцветную рождественскую елку не будет.
1. Минимум в два раза больше чего? Третьегном и юнити не менее прожорливы. Желающие сэкономить ресурсы ставят себе всякие легковесные WM и в сторону кед даже не смотрят. 2. И сколько таких кедоспецифичных приложений? Раз, два и обчёлся. Меня больше беспокоит в этом плане, что к зоопарку GTK добавится ещё и зоопарк QT. 3. Спорненько. Те же Digikam и Krita… 4. Очень спорно. Лично у меня из тех же GTK-приложений только FF, LO и GIMP. Всё остальное — на QT, или вообще, из стандартного кедонабора. Так что, это вопрос вкуса и цвета фломастеров. 5. А можно поподробнее про проприетарный набор? И как-то столлманоугодность к юзабельности если и относится, то весьма косвенно. 6. На маломощных компьютерах вообще не всё стартует. Даже LXDE уж насколько легковесно, и то на стареньком третьепне клиентов подлагивало (хотя, на моём старичке 4 года назад всё летало). Да и вообще, когда это кеды рекомендовали для маломощных машин? 7. 8. Щито? Может, у кого глючит и падает, но у меня почему-то падала плазма всего два раза, и то из-за моих криворуких экспериментов. А в остальном — работает, как швейцарские часы. 9. Пусть пилят. Может, чего путное напилят. А M$ действительно, говорят, пиратит кедоидеи. Впрочем, тут дело мутное. 10. Кому как. Лично мне дизайн вполне даже нравится. И настраивается он, если что, быстро и просто. 11. А по-моему, много настроек — это как раз, хорошо. А то, как посмотрю, все стараются подогнать всё под потребности домохозяек, которым в идеале нужна лишь кнопочка «сделать зашибись». И всё у меня работает. 12. Опять же, вопрос фломастеров.
Итак, из всей критики действительно объективным можно признать лишь прожорливость и тулкитозоопарк, что уже неоднократно обмусолено до самых костей. А всё остальное — вопрос личных предпочтений и убеждений.
Так вот я и говорю, что на этом все преимущества ubuntu server по сути и заканчиваются.
Если рассматривать linux как инструмент, с помощью которого зарабатываешь деньги, то lts - это глобальное преимущество, всё остальное уходит на второй план.
И да, в Debian ввели практику LTS релизов.
LTS так не делается, сначал мол мы поддерживали до 2014, а потом посовещались и продлили до 2016. Это не серьёзно. LTS должен объявлятся заранее с определёнными временными рамками поддержки.
Два различных дистрибутива, собираемые двума различными командами разработчиков. При этом команда Debian существует на донаты, а команда Ubuntu финансируется Canonical.
Также очень существенное различие в системе инициализации: в Ubuntu - upstart, в Debian - sysVinit (в последнем релизе заменённая на systemd).
Ну и в том, что в Убунте - убунтоюзеры.
То, что я помню, — это сообщение «Waiting up to 60 more seconds for network configuration», которое, как я тогда выяснил, не имеет никакого отношения к ожиданию конфигурации сети,
А не из-за Поттеринга ли это? Его глючного нетворк-менеджера. У меня такой проблемы не было, т.к. я его выпилил ещё в нулевых.
апстарт даже не мог уследить за процессами, которые были запущены в результате работы демона.
Если ты про форки, то они поддерживаются, есть соответствующие параметры.
Ты серьёзно? upstart-file-bridge (systemd.path), upstart-local-bridge и upstart-socket-bridge (systemd.socket), reload signal (частный случай ExecReload), cgroups в каком-то виде,
И чего ты мне ссылки на лоровские вбросы кидаешь? Ещё бы на двач сослался. Ты мне примеры кода приведи, который якобы скопировали из systemd.
также в убунте теперь используется systemd-logind (почему же?)
Потому что Поттеринг зачем-то берёт линуксовые компоненты и объединяет с кодом systemd, отдельно они уже не развиваются. Мейнтейнерам других дистров приходится эти компоненты самостоятельно оттуда выковыривать для использования в своих дистрах. Logind раньше был сам по себе. Помимо него ещё кое-что постигла та же участь, например udev, который сейчас в системе висит как systemd-udevd.
А не из-за Поттеринга ли это? Его глючного нетворк-менеджера.
Нет, не из-за него, он-то как раз стартует сразу, его ждать не надо. Такое сообщение могло появляться, если долго не удаётся получить адрес через dhcp, настроенный в /etc/network/interfaces, и тут NM только в плюс, поскольку он не будет тормозить загрузку сетевыми задержками, в отличие от настройки через /etc/network/interfaces. Но также такое сообщение могло появляться не только из-за сети, но и просто из-за того, что фаза sysinit затянулась. Интуитивный апстарт, чо, это можно было легко узнать, если отгрепать эту фразу в /etc/init.
Если ты про форки, то они поддерживаются, есть соответствующие параметры.
Это тупой неуниверсальный костыль, который разве что только и поддерживает ситуацию, когда процесс демонизировался. А я про любые запущенные демоном процессы.
И чего ты мне ссылки на лоровские вбросы кидаешь?
Это не вбросы, а новости.
Ты мне примеры кода приведи, который якобы скопировали из systemd.
А я и не говорил, что копируют код. Копируют фичи:
gentoo_root
В последнее время upstart стал просто массово переносить в себя фичи из systemd.
Мейнтейнерам других дистров приходится эти компоненты самостоятельно оттуда выковыривать для использования в своих дистрах.
Прям выковыривать? Раньше они собирали udev, теперь же systemd с --disable-всё-кроме-удева. Даже в код вмешиваться не нужно. Велика проблема, я бы понял, если бы им приходилось вынимать куски удева и патчить их, чтобы он не зависел от systemd.
Нет, не из-за него, он-то как раз стартует сразу, его ждать не надо. Такое сообщение могло появляться, если долго не удаётся получить адрес через dhcp, настроенный в /etc/network/interfaces, и тут NM только в плюс, поскольку он не будет тормозить загрузку сетевыми задержками, в отличие от настройки через /etc/network/interfaces. Но также такое сообщение могло появляться не только из-за сети, но и просто из-за того, что фаза sysinit затянулась. Интуитивный апстарт, чо, это можно было легко узнать, если отгрепать эту фразу в /etc/init.
Ну и причём тут upstart? Sysvinit оставлен для совместимости. Если в конфигах апстартовских задач прописано чтобы они запускались после поднятия сети, то эти задачи будут ждать. Ну конечно же, вместо того чтобы исправить баг с поднятием сети проще обвинить не имеющее к этому отношение.
Это тупой неуниверсальный костыль, который разве что только и поддерживает ситуацию, когда процесс демонизировался. А я про любые запущенные демоном процессы.
Прям выковыривать? Раньше они собирали udev, теперь же systemd с --disable-всё-кроме-удева. Даже в код вмешиваться не нужно. Велика проблема, я бы понял, если бы им приходилось вынимать куски удева и патчить их, чтобы он не зависел от systemd.
Вряд ли без патчинга обошлось, неужели оно изначально не зависит от systemd? Можешь посмотреть в логах у debian или ubuntu патчат ли они.
А вот такого не припомню. Пруфы в студию.
Там ConsoleKit был, который закрылся из-за logind. ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-logind!
У инженеров NASA, вероятно, есть свои аргументы, но debian 6 они выбрали до того, как его поддержку продлили до 2016 года, так что LTS их точно не интересует. Они наверняка держат свою команду разрабов, чтоб это дело поддерживать. У меня таких возможностей нет, а я должен планировать свои расходы, да и люди уходящие с red hat с удовольствием мигрируют на ubuntu lts.
Если в конфигах апстартовских задач прописано чтобы они запускались после поднятия сети
Нет, там прописано не это. Там прописано показывать сообщение о том, что сеть поднимается долго, если sysinit выполняется долго. Если до сих пор непонятно, sysinit != сеть. И уж тем более sysinit != SysVinit.
И зачем это нужно?
Чтобы следить и управлять всеми процессами, запущенными демоном.
По ссылкам я видел только вбросы. Где пруфы там?
Вбросы — первые две ссылки. Остальное — пруфы к тому, что я писал. Хорош троллить тут.
Молодец, придрался к «переносить» и «копировать». Аргументов же серьёзных нет, так даже троллишь неумело.
Вряд ли без патчинга обошлось, неужели оно изначально не зависит от systemd?
Посмотрел в gentoo в sys-fs/udev-218, там применяется только патч upstream-rejected-skip-locale_t-with-uclibc.patch. Очевидно, патч для поддержки uclibc — не патч для отделения от systemd. Так что udev вообще никак не прибит гвоздями к systemd и очень просто собирается отдельно. Впрочем, как и другие компоненты systemd.
Там ConsoleKit был, который закрылся из-за logind. ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-logind!
Потому что Поттеринг зачем-то берёт линуксовые компоненты и объединяет с кодом systemd, отдельно они уже не развиваются. <…> Logind раньше был сам по себе.
Ага, т.е. по-твоему Поттеринг взял ConsoleKit и переименовал в systemd-logind? Толсто.
Нет, там прописано не это. Там прописано показывать сообщение о том, что сеть поднимается долго, если sysinit выполняется долго.
Вот пример: start on (local-filesystems and net-device-up IFACE!=lo)
Чтобы следить и управлять всеми процессами, запущенными демоном.
Так зачем за ними следить-то?
Остальное — пруфы к тому, что я писал.
Не было. Ты мне нормальные источники дай, а не болтовню на прыщефоруме.
Молодец, придрался к «переносить» и «копировать». Аргументов же серьёзных нет, так даже троллишь неумело.
Найди получше способ слиться кроме как обвинить в троллинге.
Ага, т.е. по-твоему Поттеринг взял ConsoleKit и переименовал в systemd-logind? Толсто.
Я этого не говорил. Суть в том что из-за него закрылся в том числе и ConsoleKit. Теперь и Убунта собирается перейти на Systemd. Red Hat имеет слишком большое влияние в опенсорсе.
Вот пример: start on (local-filesystems and net-device-up IFACE!=lo)
При чём тут пример, если в убунте в /etc/init совсем не это (по крайней мере, в той версии, которой я тогда пользовался)?
Так зачем за ними следить-то?
Чтобы можно было знать, что было запущено демоном, очевидно.
Ты мне нормальные источники дай, а не болтовню на прыщефоруме.
Тебе нужно — ты и ищи другие источники, почему я должен этим заниматься, если текст новостей на ЛОРе для тебя звучит неубедительно?
Найди получше способ слиться
Мне не нужно.
Я этого не говорил.
В любом случае, твоя фраза «Logind раньше был сам по себе» — это толстое 4.2.
Суть в том что из-за него закрылся в том числе и ConsoleKit.
Вовсе нет, ConsoleKit закрылся из-за того, что был старой неподдерживаемой программой, в которой не было нормального мультисита. Logind пришлось написать из-за того, что ConsoleKit был плох. Думаю, что если бы ConsoleKit имел гибкую архитектуру и активно разрабатывался, пользовались бы им, а logind не писали бы. Возможно, его могли бы включить в пакет с systemd аналогично удеву.
Значит, там уже что-то изменили. В той убунте, в которой я испытывал эту проблему, было так, как я рассказал.
Я это и с помощью ps или htop могу узнать.
Не можешь, если дочерний процесс форкнулся.
А с какой стати я должен искать подтверждение твоим словам?
Я тебе доказывать ничего не собираюсь, я и так вижу, что тебе какие пруфы ни покажи, ты скажешь, что это неправда. А новости на ЛОРе, конечно же, от фонаря пишут, фичи в них придумывают, да.
пришлось использовать компоненты systemd отдельно от него.
И к чему это было сказано?
Поддерживался до systemd.
Уже тогда был трудноподдерживаемым и не разрабатываемым, logind вовремя пришёл на замену.
Данный пример взят из /etc/init/winbind (компонент самбы).
А, так тогда не интересно, я говорил про один из дефолтных файлов в /etc/init. Думаю, ты его найдёшь с помощью grep по сообщению, которое я показывал. Думаю, ты даже уже давно его нашёл.
Форки поддерживаются (ты не прошёл по ссылке, видимо).
В этом сообщении не было ссылки:
Я это и с помощью ps или htop могу узнать.
Если у меня был процесс A, он породил процесс B, а процесс B форкнулся и стал процессом C, то никакой ps, htop и upstart не покажет, что C был порождён A.
Тогда что пристал ко мне?
Я всего лишь отвечаю на твои сообщения.
ЛОР не является первоисточником
Под каждой новостью есть ссылка на источник или подробности. Пройди по таким ссылкам, пока не достигнешь первоисточника.
Всем было пофиг
Не всем, в ConsoleKit не было мультисита, logind делался в том числе для него.
или пруфы опять же
Сам найдёшь, у меня нет цели в жизни кому-то что-то доказать.
Только сегодня перелез с Кубунты на Демьянку. Первые, так сказать, впечатления от простого юзера, не заморачивающегося проблемами разработки. Плюсы:
Шустрее. Реально. Софт запускается раза в полтора-два быстрей, что на моей тормозоватой машине заметно. И пашет всё со скоростью мысли. Убунта же, бывало, и подлагивала. Жрёт меньше. Если раньше система вместе с кедами со старта отжирала 500 с гаком метров, теперь не лопает и 400. И вообще, сижу сейчас, открыты ФФ с десятком вкладок, Крузадер и читалка. 928 Мб. Раньше было бы гектара 1,5.
Минусы (во всяком случае, для новичка) Репы. Нет уютненьких ppa с самыми свежими версиями софта. Решается отчасти добавлением репок от LMDE. Но и там не всё. Muon тот же жалко. Где?!! Отличный гуёвый, да нет, огуенный пакетный менеджер, вместо которого стоит какое-то куцее поделие. Bomi тоже нет. Буду собирать & компилять. Отсюда и более высокий уровень красноглазия. Сегодня вот впервые сам собирал пакеты. Инфиналити, итить-колотить. А криво вставшие видеодрова выкинули меня при презагрузке прямо в ядрёную консоль. В общем, перед первой установкой стоит пошурудить по блогофорумам и прояснить все непонятные места, иначе хронический конъюктивит обеспечен. Как-то так…