Переход на новую систему инициализации insserv, учитывающую при загрузке зависимости между init-скриптами и поддерживающую параллельную загрузку скриптов инициализации, что приводит к заметному уменьшению времени загрузки
Эх, зачем они сменили aptitude обратно на apt-get?
Все уже привыкли, настроили... Конечно ничего страшного при использовании aptitude в неинтерактивном режиме я не ожидаю, но всё же наверное не зря рекомендуется использовать apt-get для обновления системы и неинтерактивной работе с пакетами.
К сожалению, оригинала этой фразы мне найти не удалось (по ссылке «основной источник новости» на опеннете её нет). Но учитывая, что aptitude давно рекомендуется разработчиками, а также разруливает конфликты не в пример лучше apt-get, подозреваю, что здесь закралась ошибка перевода.
Ну значит это очень серъёзная ошибка, так как информация с официального сайта http://www.debian.org/releases/squeeze/i38...ru.html#pkgmgmt
Ну и что бы не грешить на перевод For a non-interactive command line interface for package management, it is recommended to use apt-get. apt-get is also the preferred tool for upgrades between major releases. (http://www.debian.org/releases/squeeze/i386/release-notes/ch-whats-new.en.html#pkgmgmt)
Ну и что бы не грешить на перевод For a non-interactive command line interface for package management, it is recommended to use apt-get. apt-get is also the preferred tool for upgrades between major releases. (http://www.debian.org/releases/squeeze/i386/release-notes/ch-whats-new.en.html#pkgmgmt)
Я так понимаю, это относится к использования в скриптах, когда интерактивный интерфейс на фиг не нужен.
Я так понимаю, это относится к использования в скриптах, когда интерактивный интерфейс на фиг не нужен.
А пакеты Вы всегда ставите с использованием интерактивного интерфейса?
Например, я в интерфейс aptitude захожу крайне редко, только если хочу просмотреть список пакетов в определёной группе. А установку/удаление всегда произвожу из командной строки.
А пакеты Вы всегда ставите с использованием интерактивного интерфейса?
Например, я в интерфейс aptitude захожу крайне редко, только если хочу просмотреть список пакетов в определёной группе. А установку/удаление всегда произвожу из командной строки.
Хорошо, что тогда подразумевается под интерактивным интерфейсом?
Согласитесь, в скрипт можно вписать как вызов aptitude, так и вызов apt-get. А так как скрипт не будет взаимодействовать с пользователем, то, на мой взгляд, он не является интерактивным. То же можно сказать и о вызове из консоле, мне ничто не мешает вызвать aptitude с ключём --assume-yes и система молча поставит указанные пакеты. Разве это можно назвать интерактивной работой?
Эх, зачем они сменили aptitude обратно на apt-get?
Все уже привыкли, настроили... Конечно ничего страшного при использовании aptitude в неинтерактивном режиме я не ожидаю, но всё же наверное не зря рекомендуется использовать apt-get для обновления системы и неинтерактивной работе с пакетами.
К сожалению, оригинала этой фразы мне найти не удалось (по ссылке «основной источник новости» на опеннете её нет). Но учитывая, что aptitude давно рекомендуется разработчиками, а также разруливает конфликты не в пример лучше apt-get, подозреваю, что здесь закралась ошибка перевода.
Ну значит это очень серъёзная ошибка, так как информация с официального сайта http://www.debian.org/releases/squeeze/i38...ru.html#pkgmgmt
Ну и что бы не грешить на перевод For a non-interactive command line interface for package management, it is recommended to use apt-get. apt-get is also the preferred tool for upgrades between major releases. (http://www.debian.org/releases/squeeze/i386/release-notes/ch-whats-new.en.html#pkgmgmt)
Как я уже писал, я не нашёл этого текста на офсайте (плохо искал) — только из этого и сделал своё предположение. Раз там и в самом деле так написано, это всё действительно выглядит немного странно. Особенно рекомендация использовать apt-get для обновления релиза. Ведь aptitude действительно ощутимо лучше разруливает зависимости. Я это проверял неоднократно на aptitude и apt-get из squeeze, до которых обновился вскоре после заморозки. Поскольку для N810 aptitude слегка требователен к ресурсам, то, когда много всего висит в памяти, отдаю предпочтение apt-get/apt-cache — и имел немало возможностей сравнивать.
А пакеты Вы всегда ставите с использованием интерактивного интерфейса?
Например, я в интерфейс aptitude захожу крайне редко, только если хочу просмотреть список пакетов в определёной группе. А установку/удаление всегда произвожу из командной строки.
Интерактивный интерфейс != ncurses-интерфейс.
Т.е. в команде aptitude install something Вы видите больше интерактивности, чем в apt-get install something? Однако…
Выбор из кучи вариантов установки в случае путаницы с зависимостями.
Кстати, посмотрите, как работают apt-get и aptitude с флагом --assume-yes. Есть одно существенное отличие.
Наверное apt-get всё же "доделали", так как я обновился с его использованием без проблем, используя aptitude я думаю также не должно вызвать проблемы. Из замеченых различий - aptitude предлагал при dist-upgrade установить большее количество пакетов, в отличии от apt-get, разница не принципиальная, порядка 15-20 пакетов, но всё же.
На мой взгляд у aptitude также более понятный вывод. Для примера, установка anjuta:
sudo aptitude install anjuta
The following NEW packages will be installed:
anjuta anjuta-common{a} devhelp-common{a} libanjuta0{a} libdevhelp-1-1{a}
libgda-4.0-4{a} libgda-4.0-common{a} libgdl-1-3{a} libgdl-1-common{a}
libgladeui-1-9{a} libgraph4{a} libgtksourceview2.0-0{a}
libgtksourceview2.0-common{a} libgvc5{a} libjs-jquery{a} libpathplan4{a}
libunique-1.0-0{a} libwnck-common{a} libwnck22{a} libxdot4{a} libxres1{a}
The following packages are RECOMMENDED but will NOT be installed:
autoconf autogen automake gdb intltool javascript-common libtool yelp
0 packages upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
Need to get 16.7 MB of archives. After unpacking 54.5 MB will be used.
sudo apt-get install anjuta
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
anjuta-common devhelp-common libanjuta0 libdevhelp-1-1 libgda-4.0-4
libgda-4.0-common libgdl-1-3 libgdl-1-common libgladeui-1-9 libgraph4
libgtksourceview2.0-0 libgtksourceview2.0-common libgvc5 libjs-jquery
libpathplan4 libunique-1.0-0 libwnck-common libwnck22 libxdot4 libxres1
Suggested packages:
libgtk2.0-dev libgtkmm2.0-dev glade-gnome libgda-4.0-bin libgda-4.0-mysql
libgda-4.0-postgres
Recommended packages:
yelp automake autoconf autogen intltool gdb libtool javascript-common
The following NEW packages will be installed:
anjuta anjuta-common devhelp-common libanjuta0 libdevhelp-1-1 libgda-4.0-4
libgda-4.0-common libgdl-1-3 libgdl-1-common libgladeui-1-9 libgraph4
libgtksourceview2.0-0 libgtksourceview2.0-common libgvc5 libjs-jquery
libpathplan4 libunique-1.0-0 libwnck-common libwnck22 libxdot4 libxres1
0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
Need to get 16.7 MB of archives.
After this operation, 54.5 MB of additional disk space will be used.
В выводе aptitude чётко видно, что рекомендованные пакеты установлены не будут.
Т.е. в команде aptitude install something Вы видите больше интерактивности, чем в apt-get install something? Однако…
думаю, что авторы имел в виду запуск "aptitude" и интерактивной работе с ним.
А если писать строкой atitude install pkg, то тут предпочтительней apt-get install pkg
Я уже писал выше: aptitude значительно лучше разруливает зависимости.
А можно пример? Много раз это слышал, но так и не понял, как это возможно без участия пользователя.
Конкретики не помню, но часто такое возникало, скажем, при установке чего-то не из умолчательной ветки. В этом случае apt-get отваливался, споткнувшись даже об единственный пакет в зависимостях. А aptitude и несколько пакетов подтягивал автоматически до нужной версии. По крайней мере у меня за последние несколько месяцев цепочка «apt-get install что-нибудь — ошибка зависимостей — aptitude install то-же-самое — результат» повторялась не меньше десяти раз. Когда повторится в следующий раз, напишу конкретнее (если вовремя вспомню).
Выбор из кучи вариантов установки в случае путаницы с зависимостями.
Т.е. Вы о том случае, когда aptitude предложит варианты на выбор, а apt-get просто отвалится и предоставит разруливать всё вручную? Да, здесь действительно больше интерактивности. Но на мой взгляд, здесь она как раз оправдана. Кроме того, разве это не отключается? И последнее: в aptitude такая ситуация в принципе возникает намного реже.
А если писать строкой atitude install pkg, то тут предпочтительней apt-get install pkg
По мнению разработчиков теперь так и выходит. Но мне это странно. Аргументы в пользу aptitude привёл выше; контраргументов не могу придумать ни одного (кроме упомянутой чуть меньшей требовательности к ресурсам, которая кроме кпк и очень устаревшего железа несущественна).
Вчера проект популярного GNU/Linux-дистрибутива Debian объявил о новом крупном стабильном релизе — 6.0 «Squeeze».
Формально с новым релизом Debian некорректно называть «проектом GNU/Linux-дистрибутива», поскольку в 6.0 «Squeeze» предлагается версия с ядром другой свободной операционной системы — FreeBSD (GNU/kFreeBSD). Впрочем, пока у этой разновидности Debian статус «технологической пробы», поэтому для промышленного использования она не рекомендуется.
Итак, среди новшеств и изменений в релизе Debian GNU/Linux 6.0 «Squeeze»:
Debian GNU/kFreeBSD для 32-битной и 64-битной архитектуры (i386, amd64);
полностью свободное ядро Linux, в котором нет блобов (все они вынесены в отдельные пакеты, убраны из основного архива Debian в несвободную часть);
«система запуска на основе зависимостей, которая ускоряет загрузку, делает её более надёжной благодаря параллельному выполнению загрузочных сценариев и отслеживанию зависимостей между ними»;
совместимость с FHS v2.3 и ПО, разработанным для стандарта LSB версии 3.2;
обновленное программное обеспечение:
ядро Linux 2.6.32;
KDE Plasma Workspaces и KDE Applications 4.4.5; GNOME 2.30; Xfce 4.6; LXDE 0.5.0;
Разработка Debian 6.0 «Squeeze» продолжалась 2 года, а сам релиз неоднократно переносился.
P.S. 6 февраля, за день до релиза 6.0 «Squeeze», было объявлено об обновлении внешнего вида веб-ресурсов проекта Debian. Дизайн практически не менялся на протяжении 13 лет, поэтому событие действительно знаковое. Авторы нового оформления остались верны принципу минимализма, но сделали его в более современном виде. Убедиться можно, например, на головном сайте — debian.org.
Я пользовался. Не знаю, что там было в lenny, но у меня проблема возникла только одна, как я понимаю, ни разу не дистроспецифичная.
В Lenny оно дико тормозило, грузилось 3 минуты (правда, ставил только на virtualbox). Правда, это был далеко не релиз, и, наверное, даже не бетка, и инсталлятор предупреждал об этом.
В Lenny оно дико тормозило, грузилось 3 минуты (правда, ставил только на virtualbox). Правда, это был далеко не релиз, и, наверное, даже не бетка, и инсталлятор предупреждал об этом.
Ну помедленнее запускается, чем grub-legacy, но не критично, секунд на несколько.
А если писать строкой atitude install pkg, то тут предпочтительней apt-get install pkg
По мнению разработчиков теперь так и выходит. Но мне это странно. Аргументы в пользу aptitude привёл выше; контраргументов не могу придумать ни одного (кроме упомянутой чуть меньшей требовательности к ресурсам, которая кроме кпк и очень устаревшего железа несущественна).
Тихон, я думаю, в случае dist-upgrade разница между apt-get и aptitude действительно минимальна:
когда требуется «рубить с плеча», что микроскоп, что молоток дадут один и тот же эффект.
Тихон, я думаю, в случае dist-upgrade разница между apt-get и aptitude действительно минимальна:
когда требуется «рубить с плеча», что микроскоп, что молоток дадут один и тот же эффект.
Кстати… Рекомендуют-то его теперь, как я понял, не только при dist-upgrade, но и вообще вместо использования aptitude в «неинтерактивном» режиме.
Уж не знаю, что вы с ними делаете, но моя статистика показывает <1‰.
Моя статистика - еще меньше. Длительное время жил без бесперебойника. Ну и учитываю опыт знакомых. На винте без бед-секторов ОДИН РАЗ упала ОДНА ПАПКА (правда, этой папкой оказался /sbin и система спасена не была). Правда, на винте, который уже умирал от бедов, каждый день падало по несколько папок.
и система спасена не была). Правда, на винте, который уже умирал от бедов, каждый день падало по несколько папок.