После многочисленных переносов сроков, с опозданием почти на два месяца относительно первоначального плана доступна для тестирования (http://ru.redhat.com/about/news/archive/2012/11/fedora-beta-...) бета-версия Linux-дистрибутива Fedora 18. Перенос сроков был вызван необходимостью выделения дополнительного времени для доведения до должного вида поддержки UEFI Secure Boot, нового инструментария для обновления дистрибутива (fedup-dracut) и серьёзно переработанного инсталлятора Anaconda. Для загрузки доступна (http://fedoraproject.org/get-prerelease) как универсальная DVD-сборка, так и отдельные Live-сборки с GNOME, KDE, Xfce и LXDE. Релиз запланирован (https://fedoraproject.org/wiki/Schedule) на 8 января.
Основные новшества (https://fedoraproject.org/wiki/Fedora_18_beta_release_notes) Fedora 18:
- Реструктуризация Anaconda, переработка (http://fedoraproject.org/wiki/Features/NewInstallerUI) и упрощение пользовательского интерфейса инсталлятора. Внесённые изменения позволили избавиться от ряда ограничений, мешающих добавлению в инсталлятор новых возможностей, в частности, обеспечения поддержки новых типов хранилищ и увеличения гибкости процесса установки;
- Подготовка к интеграции (http://www.opennet.me/opennews/art.shtml?num=34000) поддержки режима безопасной загрузки UEFI. Цифровую подпись от компании Microsoft планируется внедрить непосредственно перед финальным релизом;
- Включение в дистрибутив поддержки обновления системы в offline-режиме (https://fedoraproject.org/wiki/Features/OfflineSystemUpdates), ранее предложенной (http://www.opennet.me/opennews/art.shtml?num=34035) разработчиками GNOME, PackageKit и systemd. Новый режим подразумевает установку обновлений для некоторых ключевых компонентов системы (например, glibc и других основных библиотек) на начальном этапе загрузки системы, при котором обновляемые компоненты не могут привести к конфликту и проблемам в работе уже работающих приложений. Число пакетов, которые будут обновлять в offline режиме, требующем перезагрузки, будет ограничено. Обновление большинства приложений будет производиться как и раньше на лету, при этом если в момент обновления будут выявлены запущенные графические приложения, связанные зависимостями с обновляемыми пакетами, для таких приложений будет выведено предупреждение о необходимости их перезапуска;
- Интеграция в дистрибутив в экспериментальном режиме нового пакетного менеджера DNF (https://fedoraproject.org/wiki/Features/DNF), ответвившегося от Yum 3.4 и развивающего некоторые новые идеи, такие как использование в качестве бэкенда для разрешения зависимостей библиотеки hawkey (https://fedoraproject.org/wiki/Features/Hawkey). Для разрешения зависимостей в DNF задействован SAT solver, реализованный в библиотеке libsolv (https://github.com/openSUSE/libsolv) (hawkey выступает в роли надстройки над libsolv), созданной в рамках проекта openSUSE. Для обычного пользователя главными достоинствами DNF является заметно более высокая скорость работы и низкое потребление памяти. Для расширения функциональности DNF предоставляет фикисированный API для плагинов и интеграции с другими приложениями, такими как инсталлятор Anaconda.- Переход на использование tmpfs для раздела /tmp, т.е. для хранения временных файлов будет использован размещаемый в оперативной памяти RAM-диск, который может быть вытеснен в раздел подкачки при нехватке свободной памяти. Основной причиной размещения /tmp в RAM-диске является желание сократить число операций записи на физический накопитель, что позволит снизить энергопотребление жестких дисков и продлит жизнь SSD-накопителей, а также увеличит производительность работы с временными файлами. Из недостатков нового подхода, кроме дополнительного расхода ОЗУ, отмечается отсутствие поддержки квот в tmpfs. При желании администраторы смогут отключить использование tmpfs и вернуться к прежнему методу размещения временных файлов;
- В NetworkManager реализована поддержка настройки работы в виде точки доступа к беспроводной сети (Hotspot);
- Использование свежих версий десктоп-окружений GNOME 3.6, KDE 4.9, Xfce 4.10, а также обучающей оболочки Sugar 0.98. В состав штатных репозиториев включены пакеты с MATE Desktop (http://www.opennet.me/opennews/art.shtml?num=34451) (форк GNOME 2);
- Добавление Riak (http://wiki.basho.com/), отказоустойчивой и высокомасштабируемой NoSQL БД;- Поддержка развёртывания и поддержания контроллера домена и сервиса Active Directory на базе Samba4, в том числе с поддержкой протокола SMB3 и доверительных доменов FreeIPA. Наличие средства для подсоединения Fedora 18 к домену Active Directory или FreeIPA;
- Обновление средств разработки: Python 3 стек обновлён до версии 3.3, Rails обновлён с версии 3.0 до 3.2, включены новые версия Perl 5.16 и библиотек Boost 1.50. Добавлены пакеты с инструментарием для языка Clojure;
- В состав дистрибутива включён DragonEgg, плагин к набору компиляторов GCC, заменяющий оригинальные оптимизаторы и генераторы кода GCC на аналоги, созданные в рамках проекта LLVM;
- В список поддерживаемых для сборки пакетов платформ добавлена субплатформа ppc64p7, оптимизированная для процессоров Power7;
- В дистрибутив добавлена поддержка развёртывания инфраструктуры облачных PaaS-систем (платформа как сервис) на базе системы OpenShift (http://www.opennet.me/opennews/art.shtml?num=33737);
- Включение в состав IaaS-платформы Eucalyptus (http://www.opennet.me/opennews/art.shtml?num=34317) дало возможность создания совместимых с Amazon EC2 приватных облачных систем, развёртываемых на собственных локальных серверах;
- Пакеты с облачной платформой OpenStack обновлены до последнего выпуска "Folsom". В состав также включены свежие релизы облачных платформ OpenNebula, Eucalyptus и CloudStack;
- Поддержка Heat (http://fedoraproject.org/wiki/Features/Heat) с реализацией AWS CloudFormation API для оркестровки облачных приложений на основе шаблонов и обеспечения стандартного способа запуска приложений в облачных системах на базе OpenStack;
- Поддержка live-снапшотов виртуальных машин, запущенных под управлением QEMU или libvirt, создаваемых без остановки работы гостевых систем;
- Компоненты oVirt (http://www.opennet.me/opennews/art.shtml?num=34641) обновлены до версии 3.1, добавлены надстройки для управления через GUI-инструменты;
- Добавление инструментария StorageManagement (http://fedoraproject.org/wiki/Features/StorageManagement) для организации управления системами хранения. В состав входят утилита и библиоткека libStorageMgmt с реализацией независимого от типа хранилищ интерфейса управления SAN и NAS хранилищами, а также демон targetd для организации удалённых хранилищ с экспортом на другие хосты по iSCSI;
- Интеграция в дистрибутив ownCloud (http://www.opennet.me/opennews/art.shtml?num=33909), похожей на Dropbox и Ubuntu One системы для организации хранения, синхронизации и обмена данными, размещёнными на подконтрольных внешних серверах;
- Включение в дистрибутив система трассировки LTTng (http://fedoraproject.org/wiki/Features/LTTng), которая работает на уровне ядра Linux и отличается минимальным влиянием на работу профилируемого приложения, что позволяет приблизить условия работы данного приложения к его выполнению без использования трассировки (например, позволяет выявлять проблемы с производительностью в программах, работающих в реальном режиме времени);
- Включение (http://fedoraproject.org/wiki/Features/firewalld-default) по умолчанию динамического межсетевого экрана firewalld. Firewalld запускается в виде фонового процесса, позволяющего динамически изменять правила пакетного фильтра через DBus, без необходимости перезагрузки правил пакетного фильтра и без разрыва установленных соединений. Для управления межсетевым экраном используется утилита firewall-cmd, которая значительно упрощает создание правил, отталкиваясь не от IP-адресов, сетевых интерфейсов и номеров портов, а от названий слу...URL: http://ru.redhat.com/about/news/archive/2012/11/fedora-beta-...
Новость: http://www.opennet.me/opennews/art.shtml?num=35436
> Включение по умолчанию динамического межсетевого экрана firewalld.Судя по описанию, оно ничуть не проще iptables. Вот и вопрос: пользователь все равно не полезет в cli для ковыряния fw. А администратору такой "костыль" только создает доп. трудности, лишая его гибкости.
Вообще с рядом решений крайне несогласен, хотя как десктопный - дистрибутив один из лучших и пригоден к употреблению "из коробки". Единственный из всех, что я видел, где пульса из коробки не "заикается".
> Судя по описанию, оно ничуть не проще iptables. Вот и вопрос: пользователь
> все равно не полезет в cli для ковыряния fw.А CLI там не главный интерфейс. Основной режим - управление через D-Bus из гуевых тулз.
> А администратору такой "костыль" только создает доп. трудности, лишая его гибкости.
Спорный вопрос. Поттеринг предлагает запилить туда pf-like синтаксис, а от него многие админы кипятком писают.
> Поттеринг предлагает запилить туда pf-like синтаксис, а от него многие админы кипятком писают.Что мешает просто создать аналог iptables с другим синтаксисом и зачем ради *такого* счастья вообще dbus? Может уже и есть, если кому-то было реально надо...
Мастер-ломастер как обычно предлагает фигню.
весь замут ради динамичного добавления правил. всё. в иптэйблс такое архитектурно не заделать, такчто неправильно сравнивать фаерволд и иптэйблс они факически решают разные задачи. и одно нельзя назвать заменой другому. сохранять миграционную совместимость в данном случае нецелесобразно.
> весь замут ради динамичного добавления правил. всё. в иптэйблс такое архитектурно не
> заделать, такчто неправильно сравнивать фаерволд и иптэйблс они факически решают
> разные задачи. и одно нельзя назвать заменой другому. сохранять миграционную совместимость
> в данном случае нецелесобразно.а вообще как дети малые, аналитика ситуаций этж просто до чёртиков. почему никто не умеет?
Умеют. Только же тролить будет не о чем...
> весь замут ради динамичного добавления правил. всё. в иптэйблс такое архитектурно не
> заделать, такчто неправильно сравнивать фаерволд и иптэйблс они факически решают
> разные задачи. и одно нельзя назвать заменой другому. сохранять миграционную совместимость
> в данном случае нецелесобразно.Динамическое удаление/добавление правил на правильно настроенном файрволле не нужно.
При этом, если очень хочется, решается скриптами вида
iptables -I INPUT 3 -p tcp --dport 22 -j ACCEPT && sleep 90 && iptables -D INPUT 3
Все. Ради этого нужен отдельный демон с управлением через d-bus?
> весь замут ради динамичного добавления правил. всё. в иптэйблс такое архитектурно не заделатьМалыш, не суди других по себе. Взрослым дядям нетрудно прочитать man iptables и "динамически" добавлять правила для них не представляет таких "архитектурных" проблем...
пример, пожалуйста
#49
> весь замут ради динамичного добавления правил. всё. в иптэйблс такое архитектурно не заделатьЭто чёй-то за чушь?!!!
> Что мешает просто создать аналог iptables с другим синтаксисомУже лет пять делают (nftables), да только не взлетает оно.
> и зачем ради *такого* счастья вообще dbus?
Непрограммистам вообще не понять, зачем нужны D-Bus и PolicyKit, если есть fork/exec и sudo.
А вот программисты предпочитают не удалять гланды через задницу. Есть API с авторизацией - его и надо юзать, а не городить костыли, когда программа изображает действия человека.
> А вот программисты предпочитают не удалять гланды через задницу. Есть API с авторизациейhttp://secunia.com/advisories/search/?search=dbus видели, погромист Вы наш?
http://secunia.com/advisories/search/?search=linux+kernelИ я выигрываю с разгромным счетом 1111:65.
> И я выигрываюНе-а, всего лишь отправляетесь оценивать критичность и пересчитывать на SLOC и время наблюдений.
> Не-а, всего лишь отправляетесь оценивать критичность и пересчитывать на SLOC и время наблюдений.Ну пересчитайте мне, раз уж так хотите доказать существование чайника Рассела.
>> Не-а, всего лишь отправляетесь оценивать критичность
>> и пересчитывать на SLOC и время наблюдений.
> Ну пересчитайте мне, раз уж так хотите доказать существование чайника Рассела.С какого перепугу? Это был тонкий намёк на толстые и вообще-то хорошо известные обстоятельства, а вовсе не попытки доказать очевидное до сих пор не заметившему.
>> Что мешает просто создать аналог iptables с другим синтаксисом
> Уже лет пять делают (nftables), да только не взлетает оно.Это объяснимо - значит ровно настолько "нужно".
>> и зачем ради *такого* счастья вообще dbus?
> Непрограммистам вообще не понятьОк, не имею больше вопросов.
> А вот программисты предпочитают не удалять гланды через задницу.
А они точно программисты, а не хирурги-самоучки - вы об чем вообще? :)
> Единственный из всех, что я видел, где пульса из коробки не "заикается".В мандриве тоже. Как в сусе - не знаю, но предполагаю, что и там все хорошо.
А плохо только в убунте, где криворукий мейнтейнер, и в дебиане, где внезапно, этот же самый мейнтейнер.
во фряхе - ок. в генте - ок. правда, "из коробки" относительное :)
я сам так и не начал пользоваться, т. к. iptables давно освоил.
firewalld глянул внутрь, полюбопытствовать. так вот выглядит все очень даже неплохо - я бы если выбирал что изучать - выбрал бы именно firewalld.
собственно в федоре оно работает вместе с другими "смежными" сервисами, и не навязывается.что касается - для кого вообще софт. во-первых - как раз для упомянутого пользователя - не обязательно cli, можно через gui все настраивать. для администратора - как набор готовых решений. внутри это всё равно те же правила iptables, и ничего хитрого или инновационного там нету.
ну и еще с iptables/iproute/etc. - те кто ими давно пользуется - часто не замечают, насколько софт неудобен новичкам/неспециалистам - либо из-за нестандартного подхода (так как сейчас не делают), либо перегружено - разбираться накладно.
ну и вот, а юзер что? юзер забьет и все, не так уж и нужен файрвол обычно, без него все работает.
на сервере кстати админ то же самое сделает еще скорее.
> ну и еще с iptables/iproute/etc. - те кто ими давно пользуется -
> часто не замечают, насколько софт неудобен новичкам/неспециалистамЭтот софт *не для неспециалистов*. Есть и всегда будут программы, для использования которых требуется прочитать их man *полностью*, да еще и пару общих книжек в придачу.
> на сервере кстати админ то же самое сделает еще скорее.
И однажды его заменят компетентным сотрудником. Жизнь сурова, сэр.
> Включение в дистрибутив поддержки обновления системы в offline-режиме, ранее предложенной разработчиками GNOME, PackageKit и systemdЖдем, когда Лангашеку придет "свежая и гениальная идея" сделать аналогичную "фичу" в upstart. Разумеется, любые параллели с systemd - это совпадение и клевета.
> Ждем, когда Лангашеку придет "свежая и гениальная идея" сделать аналогичную "фичу" в upstart. Разумеется, любые параллели с systemd - это совпадение и клевета.если бы [чисто гипотетически, представим] существовала бы техническая возможность автоматизированно скопировать/конвертировать соответствующий участок кода из SystemD в Upstart ---- то я уверен наверно разработчики Upstart так и сделали бы...
...но так как НЕ существует технической возможности -- то разным проектам приходиться ПОНОВОЙ реализовывать функциональность друг друга.
какбэ ничего зазарного здесь нет.
хорошие идеи -- надо перенимать, в этом не может быть ничего стыдного.
> какбэ ничего зазарного здесь нет.А мне кажется, есть. Лангасек из-за своих NIH-хотелок не только изобретает велосипед, но собирается создать нехилый гемор разработчикам DE.
> если бы [чисто гипотетически, представим] существовала бы техническая возможность автоматизированно
> скопировать/конвертировать соответствующий участок кода из SystemD в Upstart ---- то я
> уверен наверно разработчики Upstart так и сделали бы...А если бы [чисто гипотетически, представим] у Лангашека был бы мозг, он просто перестал бы насиловать труп upstart и взял готовый systemd.
Но мозга нет, и Лангашеку приходится делать кучу лишней работы:
- протестовать против перехода ubuntu на systemd
- копипастить функциональность из systemd в upstart
- про ту функциональность, которую еще не успел скопировать - утверждать, что она не нужна
- придумывать всякие тесты и отчаянно мухлевать, чтобы показать, что upstart не так уж и сильно сливает перед systemd.
> А если бы [чисто гипотетически, представим] у Лангашека был бы мозг, он
> просто перестал быЛучче б мосх был, с самого начала, у Ленарта! //Сферическая гипотеза.
> Лучче б мосх был, с самого начала, у Ленарта! //Сферическая гипотеза.Судя по всему, есть, раз с него Великая Убунта копирует.
а у нее работает тачпад на ноутбуке от Делл? никак не могу найти линукс дистрибутив с работающим тачпадом((( на десктопе убунта, юнити мне нравится))
> а у нее работает тачпад на ноутбуке от Делл?Возьми лайв да попробуй. Ядро там свежее, поэтому поддержка железа на высоком уровне.
доустанови пакет synaptics или еще какой input, в зависимости от конфигурации.
> доустанови пакет synaptics или еще какой input, в зависимости от конфигурации.synaptics не помогает(( наверное моя модель делла не для убунты))
работает.
Пальцетык работает?
У меня на Acer 3820 тач ALPS и пальцетык из коробки работает только на Кубунте и Сабайоне.
Пальцетык - это настройка пользователя, ОС тут вообще при чем? Блин, убунта по-моему совсем отучает пользователя смотреть настройки "ведь божественный Марк уже все сделал для пользователя, зачем туда лезть?"В федоре с гномом, например, заходите в настройки-> мышь и сенсорная панель, и там настраиваете, как хочется. Пальцетык включить/выключить, прокрутку скольжением пальца по правому краю или мультитачем, автовыключение при печати и прочее. Каждому ведь свое нравится. Я, конечно, понимаю, что нынче принято просто менять дистрибутив, если не нравятся дефолтные настройки до тех пор, пока не найдется такой, где дефолт лично вам удобен - но все-таки..
> нынче принято просто менять дистрибутив, если не нравятся дефолтные настройки до тех пор, пока не найдется такой, где дефолт лично вам удобенА если такого не найдется - создать новый дистр.
> Пальцетык - это настройка пользователя, ОС тут вообще при чем? Блин, убунта
> по-моему совсем отучает пользователя смотреть настройки "ведь божественный Марк уже все
> сделал для пользователя, зачем туда лезть?"
> В федоре с гномом, например, заходите в настройки-> мышь и сенсорная панель,
> и там настраиваете, как хочется. Пальцетык включить/выключить, прокрутку скольжением
> пальца по правому краю или мультитачем, автовыключение при печати и прочее.
> Каждому ведь свое нравится. Я, конечно, понимаю, что нынче принято просто
> менять дистрибутив, если не нравятся дефолтные настройки до тех пор, пока
> не найдется такой, где дефолт лично вам удобен - но все-таки..Есть проверенное мнение, что некоторые модели тачпадов до сих пор не поддерживаются и, соответственно, и не работают
на асере у меня тачпад тоже работает) а на делле она не видит его как панель,просто мышь
Latitude E6420 — работает, F17 x64
> После многочисленных поносовхе-хе - вот так правильней
> ответвившегося от Yum 3.4 и развивающего некоторые новые идеи
патология RH - плодить велосипеды
> - Переход на использование tmpfs для раздела /tmp, т.е. для хранения
> временных файлов будет использован размещаемый в оперативной памяти RAM-дискtmpfs - это не RAM-диск
> который может быть вытеснен в раздел подкачки при нехватке свободной памяти
а еще tmpfs может изменять размер "налету"
> - Включение в дистрибутив система трассировки LTTng (http://fedoraproject.org/wiki/Features/LTTng),
> которая работает на уровне ядра Linux и отличается минимальным влиянием на
> работу профилируемого приложения, что позволяет приблизить условия работы данного приложения
> к его выполнению без использования трассировки (например, позволяет выявлять проблемы
> с производительностью в программах, работающих в реальном режиме времени);понятно - их велосипедик SystemTap ничего подобного не может
>патология RH - плодить велосипедыКонечно, ведь надо держаться за родные окаменелости 10-летней давности и не рыпаться. Кстати, libsolv, используемый dnf, вообще-то, сделан в openSuSE, например.
> родные окаменелости 10-летней давности10 - не тру. Только 30-летний sysvinit, только хардкор!
>Включение в дистрибутив поддержки обновления системы в offline-режиме, ранее предложенной разработчиками GNOME, PackageKit и systemd.ну все - ждем fedora 18 pro/rt итд
>>Включение в дистрибутив поддержки обновления системы в offline-режиме, ранее предложенной разработчиками GNOME, PackageKit и systemd.
> ну все - ждем fedora 18 pro/rt итдЖдем Fedora с btrfs.
> ну все - ждем fedora 18 pro/rt итдЖдем комментаторов, которые понимают что по-старому все равно изменения вступали в силу в основном после перезагрузки. А до неё могли быть забавные ошибки у приложений, которые обновились, будучи запущенными. То, что вы могли 10 раз так делать и ничего не падало — ни о чем не говорит.
Плюс возможность обновляться на лету как бы не удаляют:
> Note that this feature does not prevent you from using yum and other commandline tools to install updates whenever you want to.
Это всё больше к PackageKit, куда приходит устрашающие изменения:
> if system updates are available, we will offer 'Install Updates & Restart' in addition to a plain 'Power Off' in the menus.
> изменения вступали в силуУх, прям канцелярщиной дохнуло.
Главное -- не говорить этого своим хостам на альте и знакомым дебианщикам. Вдруг заразно.
Вы чего злой такой. Уточню, если не так выразился: имхо понятно, что речь идет о приложениях и библиотеках, во-первых выполняющихся во время обновления, во-вторых редко перезапускающихся за сеанс работы (вкл-выкл). Особенно у тех, кто любит hibernate/suspend.
Да это там и так указано:> Replacing libraries and files while the OS is running can cause problems ranging from application crashes to inconsistent system states where processes are using different versions of a library at the same time.
И от дистрибутива эти проблемы не зависят. Плюс оттуда же:
> Also note that this feature is about implementing offline updates for GNOME. Other spins are not affected, although they could choose to use the same systemd and PackageKit infrastructure, and provide a similar experience.
> И от дистрибутива эти проблемы не зависят.Экспериментально не подтверждается.
> Экспериментально не подтверждается.Без теоретического обоснования имхо это мало что говорит.
>> Экспериментально не подтверждается.
> Без теоретического обоснования имхо это мало что говорит.Кажется, несколько месяцев тому разбирали типичные условия, при которых обновление бинарников/библиотек/данных под запущенной софтиной может приводить к неожиданным для неё и пользователя эффектам. А, вот мои пять копеек в том треде -- очередное спасибо recoll: http://www.opennet.me/openforum/vsluhforumID3/86304.html#165
Прочитал всю подветку, вроде как то же, о чем и говорили. Надежный апдейт — только с рестартом выполняющихся затронутых приложений, в общем случае. А все для всех частные учитывать вряд ли кто-то соберется (на уровне дистрибутива, не набора установок).
> Прочитал всю подветку, вроде как то же, о чем и говорили. Надежный
> апдейт — только с рестартом выполняющихся затронутых приложений, в общем случае.
> А все для всех частные учитывать вряд ли кто-то соберется (на
> уровне дистрибутива, не набора установок).Да, но.
Рестарт приложений не тоже самое, что перезагрузка. Перезагрузка не то же самое, что офлайн обновление.
Что касается сообщений о необходимости перезагрузки, или перезапуска приложений, это нужно и давно реализовано.
> Да, но.
> Рестарт приложений не тоже самое, что перезагрузка. Перезагрузка не то же самое,
> что офлайн обновление.Сложно поспорить. Оффлайн обновление включает перезагрузку, перезагрузка включает рестарт приложений. В зависимости от конкретного случая вам может больше подойти что угодно из этого.
> Что касается сообщений о необходимости перезагрузки, или перезапуска приложений, это нужно
> и давно реализовано.ЕМНИП, в том же packagekit (для федоры).
>В зависимости от конкретного случая вам может больше подойти что угодно из этого.Если оно будет опционально и никто не будет ломать традиционные апгрейды, пусть конечно будет. Может кому-то это пригодится, хотя я в случае неудачного обновления предпочёл бы оказаться в полноценной загруженной системе(и пофиксить/откатиться) до перезагрузки, а не в кастрированной оболочке, или меню с выбором из: откатиться или убиться об стену.
Но на современных разрабов Гнома и Федоры это(не ломать старое) не похоже. Когда они одержимы какой-то "новой" "гениальной" идеей, они её форсят с упёртостью баранов, а на альтернативы смотрят как Сталин на врагов народа.
> Когда они одержимы какой-то "новой" "гениальной" идеей, они её форсят с
> упёртостью баранов, а на альтернативы смотрят как Сталин на врагов народа.Ах, если бы... "Враги народа" потом порой становились маршалами да академиками.
А тут больше похоже на работу зондеркоманды СС...
> Может кому-то это пригодится, хотя я в случае неудачного
> обновления предпочёл бы оказаться в полноценной загруженной системе(и пофиксить/откатиться)
> до перезагрузки, а не в кастрированной оболочке, или меню с выбором
> из: откатиться или убиться об стену.Если фикс == откатиться (что логично), то оба варианта как-то сливаются.
> Если оно будет опционально и никто не будет ломать традиционные апгрейды, пусть
> конечно будет.
> Но на современных разрабов Гнома и Федоры это(не ломать старое) не похоже.
> Когда они одержимы какой-то "новой" "гениальной" идеей, они её форсят с
> упёртостью барановКак оно будет даже тут уже копипасты хватает.
> Если фикс == откатиться (что логично), то оба варианта как-то сливаются.откатиться это крайний и нежелательный случай, часто можно и без этого обойтись.
И разница всё равно есть. Для сравнения:
1. неудачно обновиться; посмотреть ошибки, логи, пошарить в гугле; откатиться; накатить те же обновления без проблемного пакета; если снова ошибки, то повторить;
2. перезагрузиться; подождать неудачных обновлений; откатиться; загрузиться и залогиниться; посмотреть логи, пошарить в гугле; как-то исключить проблемные пакеты; перезагрузиться; подождать обновлений; если снова ошибки, то повторить;И в первом случае можно не отрываться от работы, не отключать джаберы, IRC, качалки
Если проблемы возникли после апдейта, а не при разрешении зависимостей, то откатывать проблемный пакет скорее всего придется, если работоспособность важнее актуальности. А если не важнее, то это вообще не тот случай — загрузитесь как обычно и будете медленно листать гугл.А во втором случае будете yum'ом это дергать, все равно там намного больше функциональности, которая при этом понадобится.
> Если проблемы возникли после апдейта, а не при разрешении зависимостей, то откатывать
> проблемный пакет скорее всего придется, если работоспособность важнее актуальности.Да, естественно имеются в виду критичные для загрузки и работоспособности системы ошибки, вроде кривой переконфигурации GRUB, несобравшихся DKMS модулей или initrd и тому подобноом. Это можно исправить или откатить сразу без каких-то перезагрузок. В худшем случае мы окажемся ровно в той же ситуации, что и при оффлайн обновлении и тупо откатимся.
> А если не важнее, то это вообще не тот случай — загрузитесь
> как обычно и будете медленно листать гугл.
> А во втором случае будете yum'ом это дергать, все равно там намного
> больше функциональности, которая при этом понадобится.Ну и здесь оффлайн обновления тем более ничем не помогут.
Кстати если проблема с зависимостями, то виноватые обновления не должны в принципе накатиться и ничего откатывать не надо. Опять же перезагрузка и ожидание в оффлайне ради сообщения о конфликте зависимостей ― это пять.
> Да, естественно имеются в виду критичные для загрузки и работоспособности системы ошибки,
> вроде кривой переконфигурации GRUB, несобравшихся DKMS модулей или initrd и тому
> подобноом. Это можно исправить или откатить сразу без каких-то перезагрузок.Но до перезагрузки вы это не увидите.
> В худшем случае мы окажемся ровно в той же ситуации, что и
> при оффлайн обновлении и тупо откатимся.Вообще у вас скорее всего несколько пакетов с ядрами установлено, поэтому если вдруг что с модулями-initrd — можно просто перегрузиться в предыдущее. А если grub, то уже неважно, каким способом оно сломалось, чинить все равно одинаково.
> Кстати если проблема с зависимостями, то виноватые обновления не должны в принципе
> накатиться и ничего откатывать не надо. Опять же перезагрузка и ожидание
> в оффлайне ради сообщения о конфликте зависимостей ― это пять.Это очевидно.
> Ну и здесь оффлайн обновления тем более ничем не помогут.
Можете и к этому придраться, но их цель не в помощи когда что-то уже сломалось.
> Но на современных разрабов Гнома и Федоры это(не ломать старое) не похоже.Тсс, гномятникам вроде как раз рассольчику подвезли. Посмотрим.
> А все для всех частные учитывать вряд ли кто-то соберется (на
> уровне дистрибутива, не набора установок).А вот - собираются. В Debian передергивать сервисы предлагают автоматом при обновлении важных библиотек, типа glibc.
> А вот - собираются. В Debian передергивать сервисы предлагают автоматом при
> обновлении важных библиотек, типа glibc.Это типа такого (~ service bla restart), только без вопроса?
>> А вот - собираются. В Debian передергивать сервисы предлагают автоматом при
>> обновлении важных библиотек, типа glibc.
> Это типа такого (~ service bla restart), только без вопроса?Это именно "типа такое". Там спрашивают как раз.
Более того, все это (вплоть до списка сервисов) через debconf конфигурируется.
> Это именно "типа такое". Там спрашивают как раз.
> Более того, все это (вплоть до списка сервисов) через debconf конфигурируется.То есть зависимости еще и хардкодятся куда-то в конфиг-файл? И для рестарта каждого сервиса нужно знать, что он в данный момент не используется?
И это вы называете лучшим вариантом?
>> Это именно "типа такое". Там спрашивают как раз.
>> Более того, все это (вплоть до списка сервисов) через debconf конфигурируется.
> То есть зависимости еще и хардкодятся куда-то в конфиг-файл?А вы предлагаете узнавать зависимости телепатически - или тупо рестартить все что слинковано с библиотекой из запущенных сервисов?
Вы же баг цитировали, нет? Там довольно подробно объясняли человеку что как сделано и почему.
> И для рестарта каждого сервиса нужно знать, что он в данный момент не используется?
Это еще зачем?
> А вы предлагаете узнавать зависимости телепатически - или тупо рестартить все что
> слинковано с библиотекой из запущенных сервисов?В общем случае может получиться договориться о месте, куда если пакет сложил файлик glibc -- то перечисленные в файлике сервисы при обновлении пакета glibc надо перезапустить. На RPM-based ещё бы posttrans filetrigger обдумывал.
> В общем случае может получиться договориться о месте, куда если пакет сложил
> файлик glibc -- то перечисленные в файлике сервисы при обновлении пакета
> glibc надо перезапустить.Это переусложнение уже. В том же http://bugs.debian.org/168189 - довольно подробно объяснили почему.
> Это переусложнение уже.Это ещё и плохой пример -- в glibc2 с обратной совместимостью в общем всё хорошо (по крайней мере доныне было), но действительно есть ряд известных нюансов, которые _нечасто_ и предсказуемо стреляют: http://lists.altlinux.org/pipermail/sisyphus/2012-August/358...
>> Это переусложнение уже.
> Это ещё и плохой пример -- в glibc2 с обратной совместимостью в
> общем всё хорошо (по крайней мере доныне было), но действительно есть
> ряд известных нюансов, которые _нечасто_ и предсказуемо стреляютСпрашивается - кому лучше следить за этими ньюансами: мейнтейнерам libc или мейнтейнерам пакетов? Ответ очевиден.
> А вы предлагаете узнавать зависимости телепатически - или тупо рестартить все что
> слинковано с библиотекой из запущенных сервисов?Что значит тупо?
Список "разрешенных" сервисов вообще непонятная вещь — увидев такой вопрос от системы, первое что приходит в голову это то, что выведены действительно _все_ зависимые вещи. Иначе решение проблемы получается не то что неполное, так еще и вводящее в заблуждение ("ну я ж всё рестартонул, чего оно?..").
>> И для рестарта каждого сервиса нужно знать, что он в данный момент не используется?
> Это еще зачем?И то правда. Разве ж нас волнует, кто там что может сейчас делать по тем же sshd, samba, nfs... Х-|
>> А вы предлагаете узнавать зависимости телепатически - или тупо рестартить все что
>> слинковано с библиотекой из запущенных сервисов?
> Что значит тупо?Тупо - значит вам "немекнули", что подобное действие целиком глупое. Далеко не каждая программа будет "глючить" после обновления библиотеки. Детали - сильно зависят от того какие интерфейсы библиотеки она использует и как.
> Список "разрешенных" сервисов вообще непонятная вещь — увидев такой вопрос от системы,
> первое что приходит в голову это то, что выведены действительно _все_ зависимые вещи.И правильно приходит.
> Иначе решение проблемы получается не то что неполное, так
> еще и вводящее в заблуждение ("ну я ж всё рестартонул, чего оно?..").И это повод открыть баг и добавить еще один сервис.
>>> И для рестарта каждого сервиса нужно знать, что он в данный момент не используется?
>> Это еще зачем?
> И то правда. Разве ж нас волнует, кто там что может сейчас
> делать по тем же sshd, samba, nfs... Х-|Об этом нужно было волноваться при планировании обновлений. Или вы между релизами обновляетесь по крону?!
Если перезапуск сервиса необходим - некоторый перерыв в обслуживании будет так или иначе.
> Тупо - значит вам "немекнули", что подобное действие целиком глупое. Далеко
> не каждая программа будет "глючить" после обновления библиотеки. Детали -
> сильно зависят от того какие интерфейсы библиотеки она использует и как.А кто-то спорил? Другое дело что трекать всё вручную дело заведомо чреватое.
> И правильно приходит.
Вообще-то если б было правильно, багов типа вышеприведенного не существовало бы.
> И это повод открыть баг и добавить еще один сервис.
А можно не находить себе и другим кучу лишней работы и сделать сразу, надежнее и с большей способностью к автоматизации. Это к автоматическому определению зависимостей.
> Об этом нужно было волноваться при планировании обновлений. Или вы между
> релизами обновляетесь по крону?!Не надо насчет релизов, чтобы словить подобное обновлять полсистемы не обязательно. И к планированию, все обсуждаемые варианты как раз нацелены на то, чтобы условий для планирования было поменьше. Иначе можно было бы рекомендовать "yum update && reboot" и всё, с остальным сами разбирайтесь.
> Если перезапуск сервиса необходим - некоторый перерыв в обслуживании будет так или
> иначе.Ага. Но для этого варианта во-первых спорно "если", во-вторых есть лишний перерыв. Чего (обоих пунктов) при оффлайн-апдейте нет.
> А кто-то спорил? Другое дело что трекать всё вручную дело заведомо чреватое.Дело в том, что "трекать" это иначе - невозможно технически. Вы даже этого не понимаете?
>> И правильно приходит.
> Вообще-то если б было правильно, багов типа вышеприведенного не существовало бы.Ага, мы все за мир во всем мире... Но все, увы, как обычно.
>> И это повод открыть баг и добавить еще один сервис.
> А можно не находить себе и другим кучу лишней работы и сделать
> сразу, надежнее и с большей способностью к автоматизации.
> Это к автоматическому определению зависимостей.И какой-же? Тупо рестартить все? Или еще и перегружать сервер?
Или вы уже AI написали?
>> Об этом нужно было волноваться при планировании обновлений. Или вы между
>> релизами обновляетесь по крону?!
> Не надо насчет релизов, чтобы словить подобное обновлять полсистемы не обязательно.Обязательно. Внутри релиза ABI вообще ломаться не должен. Только у дистрибутивов для буратин.
> Ага. Но для этого варианта во-первых спорно "если", во-вторых есть лишний перерыв.
> Чего (обоих пунктов) при оффлайн-апдейте нет.Сервер *целиком* перегружается - какие вам еще "лишние перерывы"?
> Дело в том, что "трекать" это иначе - невозможно технически. Вы
> даже этого не понимаете?
> Или вы уже AI написали?Если для вас это невозможно и нужен AI, это исключительно ваши проблемы. Аналоги yum-plugin-ps, думаю, во многих дистрах имеются, и определить, зависит ли кто-то выполняющийся в данный момент от обновленного файла не так сложно. Пусть не однострочник, но ИИ точно не нужен.
> Ага, мы все за мир во всем мире... Но все, увы,
> как обычно.Главное чтобы это не были оправдания нежеланию признать что может быть и лучше, и это не так сложно.
> И какой-же? Тупо рестартить все? Или еще и перегружать сервер?
Вот же туго идет. Для вашего варианта — пусть будут вопросы, но не из хардкоденого списка же. Определять зависимости в рантайме и тупее, и надежнее.
> Обязательно. Внутри релиза ABI вообще ломаться не должен. Только у
> дистрибутивов для буратин.Таковые, надо понимать, все, которые не с коммерческой поддержкой. Иначе должно или не должно, но никто вам ничего не обещал.
> Сервер *целиком* перегружается - какие вам еще "лишние перерывы"?
При рестарте служб. В дополнение к перегрузке всей машины. Чесслово, будто через переводчик общаемся.
>> Дело в том, что "трекать" это иначе - невозможно технически. Вы
>> даже этого не понимаете?
>> Или вы уже AI написали?
> Если для вас это невозможно и нужен AI, это исключительно ваши проблемы.А может вы просто не понимаете сложности задачи?
> Аналоги yum-plugin-ps, думаю, во многих дистрах имеются, и определить, зависит ли
> кто-то выполняющийся в данный момент от обновленного файла не так сложно.Но вы не знаете как, я угадал? И не вы один - yum-plugin-ps тоже хлопцам никак не помог...
Давайте на конкретном примере цитированного вами бага - от какого "файла" вы предлагаете включить зависимость? И как это поможет...
> Пусть не однострочник, но ИИ точно не нужен.
Вам, видимо, и собственный интеллект не нужен...
>> И какой-же? Тупо рестартить все? Или еще и перегружать сервер?
> Вот же туго идет. Для вашего варианта — пусть будут вопросы, но
> не из хардкоденого списка же. Определять зависимости в рантайме и тупее,
> и надежнее.И как это сделать, "гуру"? Как в "рантайме" вы предлагаете отличить случаи, когда обновление libc поломает samba и когда - не поломает?
>> Обязательно. Внутри релиза ABI вообще ломаться не должен. Только у
>> дистрибутивов для буратин.
> Таковые, надо понимать, все, которые не с коммерческой поддержкой.Не все. Учите матчасть.
>> Сервер *целиком* перегружается - какие вам еще "лишние перерывы"?
> При рестарте служб. В дополнение к перегрузке всей машины.Ну и зачем мне сдалась перезагрузка всей машины, если она для обновления не нужна?
Вы тест Тьюринга готовы пройти?
> А может вы просто не понимаете сложности задачи?
> Но вы не знаете как, я угадал?
> Вам, видимо, и собственный интеллект не нужен...Вы повторяетесь. Ладно бы по делу, но с оскорблениями... фи. Собственное невежество прикрываем, небось.
> Давайте на конкретном примере цитированного вами бага - от какого "файла" вы
> предлагаете включить зависимость? И как это поможет...
> И как это сделать, "гуру"? Как в "рантайме" вы предлагаете отличить
> случаи, когда обновление libc поломает samba и когда - не поломает?О, прогресс. Если бы вы подумали чуть больше, то возможно пришли бы к мысли, что отличать вторые не обязательно, и чтобы рекомендовать рестарт хватит возможности первых. Лишний раз перестраховаться — невелика цена за исключение "ИИ" и заведомо более худшей ручной работы.
Как при обновлении узнать, изменились ли используемые запущенными приложениями файлы, надеюсь вы представляете?> Не все. Учите матчасть.
> Вы тест Тьюринга готовы пройти?С такими учителями/проверяющими — упаси б-же.
> Ну и зачем мне сдалась перезагрузка всей машины, если она для обновления
> не нужна?Омфг. Компьютер выключить, например. Или вы таким принципиально не занимаетесь?
>> Давайте на конкретном примере цитированного вами бага - от какого "файла" вы
>> предлагаете включить зависимость? И как это поможет...
>> И как это сделать, "гуру"? Как в "рантайме" вы предлагаете отличить
>> случаи, когда обновление libc поломает samba и когда - не поломает?
> О, прогресс. Если бы вы подумали чуть больше, то возможно пришли бы
> к мысли, что отличать вторые не обязательноНет, детка - обязательно. В этом и сложность задачи.
> Лишний раз перестраховаться — невелика цена за исключение
> "ИИ" и заведомо более худшей ручной работы.В чем "заведомо худшая ручная работа"? Обычная работа мейнтейнера библиотеки: посмотреть что изменилось в релизе и кому от этого достанется.
> Как при обновлении узнать, изменились ли используемые запущенными приложениями файлы,
> надеюсь вы представляете?Я не представляю одного - что это фигулька вам даст...
> Омфг. Компьютер выключить, например. Или вы таким принципиально не занимаетесь?
Сервера очень редко выключают, скажем так.
> Нет, детка - обязательно. В этом и сложность задачи.Объясняйте почему, или.. ну вы поняли. Я свою позицию описал достаточно.
> В чем "заведомо худшая ручная работа"? Обычная работа мейнтейнера библиотеки: посмотреть
> что изменилось в релизе и кому от этого достанется.В существовании цитированных багов. Говорил уже.
> Я не представляю одного - что это фигулька вам даст...
То, что мы тут обсуждаем, епт. Не пропустить значимое обновление.
> Сервера очень редко выключают, скажем так.
Ага. Там ниже вопросик остался, который вы проигнорировали. Перефразируя, у вас на всех серверах gnome и packagekit?
Серверам да, оффлайн-апдейт как раз не особо актуален, там полезнее что-то типа второго подхода с рекомендациями сразу после апдейта, который мы тут тоже пережевываем. Но для однопользовательской машины (где скорее всего и будет стоять PK) первая фича пригодится.
>> Нет, детка - обязательно. В этом и сложность задачи.
> Объясняйте почему, или.. ну вы поняли.Потому тупая перезагрузка всего и вся не удовлетворяет условиям задачи? Потому, что простой сервисов стремятся свести к минимуму. Если перезагружать сервис нет необходимости - и не надо этого делать.
>> В чем "заведомо худшая ручная работа"? Обычная работа мейнтейнера библиотеки: посмотреть
>> что изменилось в релизе и кому от этого достанется.
> В существовании цитированных багов. Говорил уже.Лучше потерпеть баги на testing, чем лишний простой при обновлении дистрибутива.
>> Я не представляю одного - что это фигулька вам даст...
> То, что мы тут обсуждаем, епт. Не пропустить значимое обновление.Во дает, демагог. И как, родной?
>> Сервера очень редко выключают, скажем так.
> Ага. Там ниже вопросик остался, который вы проигнорировали. Перефразируя, у вас на
> всех серверах gnome и packagekit?Речь шла о том, что под топор попадут не только десктопный вещи. Хотя и десктоп перегружать лишний раз, мягко говоря, не хочется.
> Серверам да, оффлайн-апдейт как раз не особо актуален
Рад, если вы хоть что-то поняли, наконец.
> Потому тупая перезагрузка всего и вся не удовлетворяет условиям задачи? Потому,
> что простой сервисов стремятся свести к минимуму. Если перезагружать сервис
> нет необходимости - и не надо этого делать.Это _не_ перезагрузка всего и вся. Это рекоммендация перезагрузки (как сейчас) зависимых вещей. При выборе между перегрузить ненужное и не перегрузить нужное я выбираю первое.
А для систем, где действительно важна непрерывность обслуживания, никакими решениями типа обсуждаемых все равно ограничиться не выйдет. Без упомянутых стендов для тестов, живой миграции клиентов и подобного так работать совсем опасно.
> Лучше потерпеть баги на testing, чем лишний простой при обновлении дистрибутива.
О, уже тестинг появился. А стейбл наверное зачарованным кругом очерчен.
> Во дает, демагог. И как, родной?
В своих же показаниях путаемся?
> Речь шла о том, что под топор попадут не только десктопный вещи.
Где шла и почему вдруг попадут?
> Хотя и десктоп перегружать лишний раз, мягко говоря, не хочется.
А лишний и не надо.
>> Серверам да, оффлайн-апдейт как раз не особо актуален
> Рад, если вы хоть что-то поняли, наконец.А кто-то спорил? Поищите указания на задачи системы в начале обсуждения. При том, что про гном и PK упоминалось не раз.
>> Потому тупая перезагрузка всего и вся не удовлетворяет условиям задачи? Потому,
>> что простой сервисов стремятся свести к минимуму. Если перезагружать сервис
>> нет необходимости - и не надо этого делать.
> Это _не_ перезагрузка всего и вся. Это рекоммендация перезагрузки (как сейчас) зависимых вещей.Это именно "перезагрузка всего и вся". Т.к. от вещей типа libc - "зависит" именно "все и вся".
> При выборе между перегрузить ненужное и не перегрузить нужное я
> выбираю первое.А я выбираю перезапустить только нужное. Благо есть такой вариант.
> А для систем, где действительно важна непрерывность обслуживания, никакими решениями типа
> обсуждаемых все равно ограничиться не выйдет.Знаете - где-то вполне "выйдет". Задачи у "шиштем" разные бывают, равно как и возможности их владельцев. Так что нехорошо выкидывать под предлогом "не шмогла" вещи, которые сейчас вполне работоспособны, если приложить небольшие усилия мейнтейнерам дистрибутива.
>> Лучше потерпеть баги на testing, чем лишний простой при обновлении дистрибутива.
> О, уже тестинг появился. А стейбл наверное зачарованным кругом очерчен.Да.
>> Речь шла о том, что под топор попадут не только десктопный вещи.
> Где шла и почему вдруг попадут?Читаем в обсуждаемой статье:
-->8--
Включение в дистрибутив поддержки обновления системы в offline-режиме ... Новый режим подразумевает установку обновлений для некоторых ключевых компонентов системы (например, *glibc* и других основных библиотек) ...
-->8--Не прошли вы тест Тьюринга...
>> Хотя и десктоп перегружать лишний раз, мягко говоря, не хочется.
> А лишний и не надо.Что в лоб - что по лбу..
> Это именно "перезагрузка всего и вся". Т.к. от вещей типа libc
> - "зависит" именно "все и вся".Это если обновилась именно libc. В подавляющем большинстве случаев будет не так. А когда так, лучше не полагаться на кого-то и да, перезапустить зависимые вещи.
> А я выбираю перезапустить только нужное. Благо есть такой вариант.
При этом вы не уверены полностью, все ли перезапустили.
> Так что нехорошо выкидывать под
> предлогом "не шмогла" вещи, которые сейчас вполне работоспособны, если приложить небольшие
> усилия мейнтейнерам дистрибутива.Если они настолько небольшие, почему вообще существует то предложение перезапуска в дебиане? Или это только в тестингах, а в стейбле его нет и не будет?
Насколько помню, вы считаете что проблема проявляется только при несовместимых ABI и если за этим следить, её быть не должно. Поправьте, если что.>>> Лучше потерпеть баги на testing, чем лишний простой при обновлении дистрибутива.
>> О, уже тестинг появился. А стейбл наверное зачарованным кругом очерчен.
> Да.Покажите! :)
>>> Речь шла о том, что под топор попадут не только десктопный вещи.
>> Где шла и почему вдруг попадут?
> Читаем в обсуждаемой статье:
> -->8--
> Включение в дистрибутив поддержки обновления системы в offline-режиме ... Новый режим подразумевает
> установку обновлений для некоторых ключевых компонентов системы (например, *glibc* и других
> основных библиотек) ...
> -->8--
> Не прошли вы тест Тьюринга...А точно я? Где там отрубание чего-то у недесктопных вещей? Максимум в systemd добавления, но вы вряд ли об этом.
На всякий случай: там прямо пообещали оставить существующее поведение у всего, что не gnome-packagekit.>>> Хотя и десктоп перегружать лишний раз, мягко говоря, не хочется.
>> А лишний и не надо.
> Что в лоб - что по лбу..Ну извините, что для сабжевой (десктопной) фичи это как раз так.
> Не знаю что вы там "писали", но в качестве примера привели ровно один баг.
А сколько нужно? Взял первый попавшийся. Шигорин еще похожее показывал. Для осознания проблем вашего подхода этого имхо достаточно.
> Но пока ничего конкретного по этому поводу вы не предложили, увы.
Опять же, не надо. Я предложил, конкретное. Другое дело что оно вас не устраивает, вот так и пишите :)
>> Это именно "перезагрузка всего и вся". Т.к. от вещей типа libc
>> - "зависит" именно "все и вся".
> Это если обновилась именно libc. В подавляющем большинстве случаев будет не так.
> А когда так, лучше не полагаться на кого-то и да, перезапустить зависимые вещи.Не решайте за всех что лучше. На работу мейнтейнеров дистрибутива я вполне озознанно расчитываю, и подводило меня это редко. Если у вас нет такой возможности - смените дистрибутив.
Администратор *всегда* имеет возможность перестраховаться - и хоть сервер целиком перезапустить... Плохо другое - когда всякие не шибко разумные мартышки ограничивают возможности его выбора.
>> А я выбираю перезапустить только нужное. Благо есть такой вариант.
> При этом вы не уверены полностью, все ли перезапустили.Вполне уверен.
>> Так что нехорошо выкидывать под
>> предлогом "не шмогла" вещи, которые сейчас вполне работоспособны, если приложить небольшие
>> усилия мейнтейнерам дистрибутива.
> Если они настолько небольшие, почему вообще существует то предложение перезапуска в дебиане?Потому что в дебиан разработчики действительно приложили необходимые усилия и решили проблему. "То предложение" - и есть итог нормального решения проблемы.
> Или это только в тестингах, а в стейбле его нет и не будет?
> Насколько помню, вы считаете что проблема проявляется только при несовместимых ABI и
> если за этим следить, её быть не должно. Поправьте, если что.При обновлении внутри stable - да, это обычно не нужно. В принципе, теоретически могут быть ситуации, когда в stable исправление какой-то ошибки поломает ABI. Но примеров такого я привести не могу.
Нужно - для обновления между релизами (oldstable -> stable).
> А точно я? Где там отрубание чего-то у недесктопных вещей?
Пардон, отвечали на *ваше* сообщение, я его процитировал. В цитате идет речь о glibc - это весьма "недесктопная" вещь.
Короче, где BTS вашего разработчика? У вас еще и с парсингом текста проблемы...
>> Не знаю что вы там "писали", но в качестве примера привели ровно один баг.
> А сколько нужно? Взял первый попавшийся. Шигорин еще похожее показывал.Шигорин показывал в ALTе, к дебиан он не имел отношения. В том, что показали вы - не вижу ничего страшного. Обычная работа над релизом.
>> Но пока ничего конкретного по этому поводу вы не предложили, увы.
> Опять же, не надо. Я предложил, конкретное.Какое? Что мне сделать, чтобы определить необходимость перезапуска сервиса автоматически? И *не трогать его, если это не требуется*.
> Не решайте за всех что лучше. На работу мейнтейнеров дистрибутива я
> вполне озознанно расчитываю, и подводило меня это редко.
> Если у
> вас нет такой возможности - смените дистрибутив.А можно избавиться и от этого, хоть и ценой оверхеда с другой стороны. "Редко" тоже не всех устраивает.
> Плохо другое - когда всякие не шибко разумные мартышки ограничивают
> возможности его выбора.
> Пардон, отвечали на *ваше* сообщение, я его процитировал. В цитате идет
> речь о glibc - это весьма "недесктопная" вещь.Какой же вы скучный. Может покажете эти ограничения наконец? У вас не отбирали возможность обновить хоть glibc хоть что, хоть на лету хоть как. А тем более если речь (уже) о серверах.
> Вполне уверен.
> Потому что в дебиан разработчики действительно приложили необходимые усилия и решили проблему.Нет. 115й раз — баги попадаются.
> "То предложение" - и есть итог нормального решения проблемы.
> При обновлении внутри stable - да, это обычно не нужно. В
> принципе, теоретически могут быть ситуации, когда в stable исправление какой-то ошибки
> поломает ABI. Но примеров такого я привести не могу.
> Нужно - для обновления между релизами (oldstable -> stable).Ну вот, ЧТД. То внутри стейбл не может быть обновлений ABI, иначе дистрибутив в топку, то все таки может и пусть тулза будет (то, что я не раз писал). А с oldstable -> stable еще интереснее — вы при этом собираетесь только перезапуском запрошенных сервисов ограничиться и всё? И будете уверены, что когда все-таки перезапуститься придется, проблем не будет?
> Короче, где BTS вашего разработчика? У вас еще и с парсингом
> текста проблемы...Нет, это у вас с оскорбленими, когда сказать нечего (:
> Шигорин показывал в ALTе, к дебиан он не имел отношения.
И? В новости вообще федора, но это не помешало вам начать её комментировать.
Мерять у кого мэйнтейнеры толще лично я не собираюсь, проблема достаточно общая.> В
> том, что показали вы - не вижу ничего страшного. Обычная
> работа над релизом.То же самое можно сказать и про любой некоммерческий дистрибутив. Который, как бы там ни было, все-таки ничего вам не должен, кроме написанного в лицензии.
> Какое? Что мне сделать, чтобы определить необходимость перезапуска сервиса автоматически?
> И *не трогать его, если это не требуется*."У вас с парсингом текста проблемы"©
Могу еще пожевать, не сложно: при обновлении пройтись по запущенным процессам, собрать список из них самих + используемые .so, найти пересечения со списком затрагиваемых обновлением файлов. Для получившегося списка предложить рестарт использующих приложений.
Можно на этом и остановиться, можно еще для паранойи опционально добавить второй проход: первый список отмапить в список пакетов, собрать все их зависимости, при обновлении которых добавить зависимое приложение в предложение рестарта.
Без этого вы не будете уверены, всё ли перезапустили, что бы там не утверждали. А рестарт сервера целиком, если я ничего не упустил, не должен будет иметь отличий даже теоретически (исключая апдейты загрузчика-ядра-.., но мы не о них), и будет просто излишним.
>> В дебиан нет гарантии, что ABI абсолютно не изменится внутри стабильного релиза.
> То, что я говорил — в некоммерческих нигде нет.Вы точно по-русски читать умеете? Такую гарантию формально никто и никогда не дает - безопасность или исправление критических проблем (с возможной потерей данных пользователй, к примеру) имеет очевидный всем приоритет над сохранением даже API, не то что ABI...
Это просто - норма для дистрибутивов с аналогичной практикой релизов.
>> Отобрали. Теперь для "хоть как" - нужно перезагрузить сервер.
>> Вы идиот или действительно бот? Такое впечатление, что все написанное вам
>> ранее - в новом посте забываете напроч.
> У меня такое же впечатление про ваши способности читать, и цитаты, и
> пересказ. Вы утверждаете неправду. Тут очередной раз.Тогда просим модераторов исправить "неправду" в новости:
-->8--
Новый режим подразумевает установку обновлений для некоторых ключевых компонентов системы (например, glibc и других основных библиотек) на начальном этапе загрузки системы
-->8--
?Вам все слова понятны? Вам понятно, что после "установки обновлений ключевых компонентов" - потребуется теперь перегрузить сервер, чтобы эти самые обновления были применены?
>> Это неверно. Вы будете рестартить приложения даже при любых обновлениях.
>> Даже если оное приложение никак затрагиваемый функционал не использует.
> И тут. Если никак не использует — то не попадет в эти
> списки (не будет зависимо).Как же так "не попадет"? Описанная вами процедура неприменно покажет "пересечения" используемых приложением *.so и обновленных - просто даже если приложение слинковано с библиотекой.
Но это не означает, что приложение неприменно использует *все* функции библиотеки или даже *именно те*, что затрагивает обновление.
>> В дебиан нет гарантии, что ABI абсолютно не изменится внутри стабильного релиза.
> Вы точно по-русски читать умеете? Такую гарантию формально никто и никогда
> не даетОтлично умею. Было противоположное:
> Обязательно. Внутри релиза ABI вообще ломаться не должен. Только у дистрибутивов для буратин.
например, и
>> О, уже тестинг появился. А стейбл наверное зачарованным кругом очерчен.
> Да.--
> Тогда просим модераторов исправить "неправду" в новости:
> -->8--
> Новый режим подразумевает установку обновлений для некоторых ключевых компонентов системы
> (например, glibc и других основных библиотек) на начальном этапе загрузки системы
> -->8--
> ?Новый режим — добавленный. Вы утверждаете:
> Отобрали. Теперь для "хоть как" - нужно перезагрузить сервер.
Новость права, а вы нет.
> Вам все слова понятны? Вам понятно, что после "установки обновлений ключевых
> компонентов" - потребуется теперь перегрузить сервер, чтобы эти самые обновления были
> применены?Мне понятно, что вы осознанно врете.
> Как же так "не попадет"? Описанная вами процедура неприменно покажет "пересечения"
> используемых приложением *.so и обновленных - просто даже если приложение слинковано
> с библиотекой.
> Но это не означает, что приложение неприменно использует *все* функции библиотеки или
> даже *именно те*, что затрагивает обновление.Ааа, так вот как вы понимаете нужность рестарта. Гранулярность по функциям. Потрясающе.
> Отлично умею.Сам не похвалишь - никто не похвалит...
> Было противоположное:
>> Обязательно. Внутри релиза ABI вообще ломаться не должен. Только у дистрибутивов для буратин.
> например, и
>>> О, уже тестинг появился. А стейбл наверное зачарованным кругом очерчен.
>> Да.Ну так о том и речь! "Зачарованный круг" - обычная практика по включению изменений в стабильный релиз. Да, ABI ломать там - не принято, и дебиан тут не исключение.
> --
>> Тогда просим модераторов исправить "неправду" в новости:
>> -->8--
>> Новый режим подразумевает установку обновлений для некоторых ключевых компонентов системы
>> (например, glibc и других основных библиотек) на начальном этапе загрузки системы
>> -->8--
>> ?
> Новый режим — добавленный. Вы утверждаете:
>> Отобрали. Теперь для "хоть как" - нужно перезагрузить сервер.
> Новость права, а вы нет.Мне еще раз процитировать? Пожалуйста:
* Новый режим подразумевает установку обновлений для некоторых ключевых компонентов системы
(например, glibc и других основных библиотек) на начальном этапе загрузки системы*Для самых маленьких: "на начальном этапе загрузки" - подразумевает перезапуск системы. Если у вас с русским языком такие проблемы - могу процитировать первоисточник:
"...if system updates are available, we will offer 'Install Updates & Restart' in addition to a plain 'Power Off' in the menus.">> Как же так "не попадет"? Описанная вами процедура неприменно покажет "пересечения"
>> используемых приложением *.so и обновленных - просто даже если приложение слинковано
>> с библиотекой.
>> Но это не означает, что приложение неприменно использует *все* функции библиотеки или
>> даже *именно те*, что затрагивает обновление.
>
> Ааа, так вот как вы понимаете нужность рестарта. Гранулярность по функциям.Я лишь указал вам на то, что одна линковка программы к обновленной библиотеке *не позволяет* утверждать, что конкретное обновление затрагивает работу этой программы. Это вам недоступно?
> Для самых маленьких: "на начальном этапе загрузки" - подразумевает перезапуск системы.
> Если у вас с русским языком такие проблемы - могу
> процитировать первоисточник:
> "...if system updates are available, we will offer 'Install Updates & Restart'
> in addition to a plain 'Power Off' in the menus."А теперь все-таки разуйте глаза и убедитесь что это относится к добавляемой фиче. А про возможности yum, которые как вы утверждаете тоже отобрали, там прямо сказано — они остаются.
> Я лишь указал вам на то, что одна линковка программы к обновленной
> библиотеке *не позволяет* утверждать, что конкретное обновление затрагивает работу этой
> программы. Это вам недоступно?Пишите еще.
>> Для самых маленьких: "на начальном этапе загрузки" - подразумевает перезапуск системы.
>> Если у вас с русским языком такие проблемы - могу
>> процитировать первоисточник:
>> "...if system updates are available, we will offer 'Install Updates & Restart'
>> in addition to a plain 'Power Off' in the menus."
>
> А теперь все-таки разуйте глаза и убедитесь что это относится к добавляемой
> фиче. А про возможности yum, которые как вы утверждаете тоже отобрали,
> там прямо сказано — они остаются.Ткните в место, где это "прямо сказано". Все, что "прямо сказано" по ссылке - я вам процитировал. В федоре будет сделано так и не иначе - и ничего после этого не "остается". Речь шла о конкретном добавлении, сделанном в федоре, а не о каких-то мифических "возможностях yum".
>> Я лишь указал вам на то, что одна линковка программы к обновленной
>> библиотеке *не позволяет* утверждать, что конкретное обновление затрагивает работу этой
>> программы. Это вам недоступно?
>
> Пишите еще.Таки недоступно?
> Ткните в место, где это "прямо сказано". Все, что "прямо сказано"
> по ссылке - я вам процитировал. В федоре будет сделано
> так и не иначе - и ничего после этого не "остается".В какой раз вы там соврамши?
> Note that this feature does not prevent you from using yum and other commandline tools to install updates whenever you want to.
Причем эта строка цитируется в треде уже третий раз. Идите высыпайтесь.
И вот так проходит критика многих нововведений, хоть в федоре, хоть где...
>> Note that this feature does not prevent you from using yum and other commandline tools to install updates whenever you want to.
> Причем эта строка цитируется в треде уже третий раз. Идите высыпайтесь.Мда, согласен :(
Впрочем, это мало что меняет. Сделан первый шаг - но в неправильном направлении. Вполне могут дальше и yum на это завязать, какие проблемы?
> И вот так проходит критика многих нововведений, хоть в федоре, хоть где...
Как "так"? Критиковалось-то совершенно другое. Вовсе не то, *где* "нововведение" реализовано, а *что* и *как*.
Как вы думаете, как разработчики будут реагировать на баги, открытые после обновления "обычным yum"? Будут они считать такие вещи штатными? Будут подсказывать какие сервисы перезапустить пользователю после обновления libc?
То-то. А вы говорите - десктоп...
Ваш пессимизм непробиваем. Вообще тут на 21е конец света планируют, а мы тут о каких-то апдейтах.> Впрочем, это мало что меняет.
> Как "так"? Критиковалось-то совершенно другое.Это меняет то, что половина ненависти оказалась в никуда. Так как критиковалась и безальтернативность в том числе.
Реагировать на баги должны будут как минимум пока/если такой способ не огласят рекомендованным. Что маловероятно из-за узости охвата, только десктоп и только гном. Обсуждать что там может случится оставим специально обученным аналитикам.
Да даже в таких вариантах попадаются группы по интересам, которые поддержат и нерекомендованный вариант.Насчет подсказок, в РК afaik автоматические подсказки давно присутствуют. Для серверов должен помогать тот же yum-plugin-ps, если не работает — код свободен, багзилла открыта.
add: еще needs-restarting есть из yum-utils, для того же.
> Ваш пессимизм непробиваем. Вообще тут на 21е конец света планируют, а мы
> тут о каких-то апдейтах.Это, извините, мистика. А мой "пессимизм" основан на уже печально известных последствиях "инноваций" из федоры. Форка udev, к примеру...
>> Впрочем, это мало что меняет.
>> Как "так"? Критиковалось-то совершенно другое.
> Это меняет то, что половина ненависти оказалась в никуда. Так как критиковалась
> и безальтернативность в том числе.Безальтернативность никуда не делась. Чтобы обновления "в yum" не приводили к трудно выводимым "глюкам" - пакеты должны поддерживать такие сценарии обновления. Ясно, что такого не будет (это и сейчас у них плохо получается, от того и "нововведение") - и разработчики нацелены на "новую фишку".
Ненависти нет, вы напрасно. Есть констатация грустного факта. А так, проблемы федоры - это проблемы федоровцев... Nobody cares.
> Реагировать на баги должны будут как минимум пока/если такой способ не огласят
> рекомендованным. Что маловероятно из-за узости охвата, только десктоп и только гном.Опять "только десктоп"? С чего вы взяли, что systemd - только десктоп? Его всюду суют, обещают в новый RHEL включить.
> Это, извините, мистика. А мой "пессимизм" основан на уже печально известных
> последствиях "инноваций" из федоры. Форка udev, к примеру...Вот смотрите — вы б радоваться должны, что можно просто форкнуть актуальную полную кодовую базу и развивать куда хочется, если кому-то взбрело не туда. Так нет же.
> Безальтернативность никуда не делась. Чтобы обновления "в yum" не приводили к
> трудно выводимым "глюкам" - пакеты должны поддерживать такие сценарии обновления.Еще про пакетирование давайте начнем постов на 40. Инструменты в помощь есть, голова есть, этого хватит. Есть проблемы хуже.
> Есть констатация грустного факта. А так, проблемы федоры - это проблемы федоровцев... Nobody cares.
"Сударь, я скакала за вами три дня, чтобы сказать как вы мне безразличны". Ну я ладно, федору же и использую. Но вы да... don't care явно :)
> Опять "только десктоп"? С чего вы взяли, что systemd - только
> десктоп? Его всюду суют, обещают в новый RHEL включить.Да прочитайте наконец куда фичу добавляют, в конце-концов. В systemd там только часть, бесполезная и беспомощная без остального.
> Вот смотрите — вы б радоваться должны, что можно просто форкнуть актуальную
> полную кодовую базу и развивать куда хочется, если кому-то взбрело не
> туда. Так нет же."Stop this crazy." (c) - куда уж тут "радоваться"...
> Еще про пакетирование давайте начнем постов на 40.
Зачем "начинать"? Аргументы прежние, ничего ни добавить - ни убавить.
>> Есть констатация грустного факта. А так, проблемы федоры - это проблемы федоровцев... Nobody cares.
> "Сударь, я скакала за вами три дня, чтобы сказать как вы мне
> безразличны". Ну я ладно, федору же и использую. Но вы да...
> don't care явно :)Потому что помимо федоры есть RHEL. Вот если это туда попадет - пропал калабуховский дом. Хотя вы, конечно, правы - там ожидаются и похуже проблемы...
> Да прочитайте наконец куда фичу добавляют, в конце-концов. В systemd там только
> часть, бесполезная и беспомощная без остального.Самая главная часть. В packagekit - так, ерунда.
>> Еще про пакетирование давайте начнем постов на 40.
> Зачем "начинать"? Аргументы прежние, ничего ни добавить - ни убавить.Да уж, и ругани добавлять не стоит... коллеги, оба ж не дети уже явно -- будьте спокойней, очень прошу.
Да мы уже всё.. вроде :)
> Потому что помимо федоры есть RHEL. Вот если это туда попадет
> - пропал калабуховский дом. Хотя вы, конечно, правы - там
> ожидаются и похуже проблемы...Для протокола — имел в виду в линуксах в общем. И опять же, с вашей точки зрения никто не пропал, наоборот, больше людей пойдут с RH на более достойные дистрибутивы.
> Самая главная часть. В packagekit - так, ерунда.
РК это всё запускать будет. Часть systemd без этого должна быть вообще неактивна.
> с вашей точки зрения никто не пропал, наоборот, больше людей
> пойдут с RH на более достойные дистрибутивы.птичку жалко...
>> Самая главная часть. В packagekit - так, ерунда.
> РК это всё запускать будет.Я ж и говорю - ерунда.
> Надежный апдейт — только с рестартом выполняющихся затронутых приложений, в общем случае.В настолько общем -- тогда уж и со штатным ребутом в контролируемое/удобное время, а вообще это обычный трейдофф. Например, в случае стопки хостов может быть куда проще обкатать обновление на стенде и даже если не предусмотрены средства автоматического перезапуска нужного -- написать скрипт/рецепт для своего случая.
Так что продолжаю морщиться от того, как шляпники переваливают на юзеров свои проблемы, не желая их _решать_. К ним точно никто из некрософта не переходил? :(
> В настолько общем -- тогда уж и со штатным ребутом в контролируемое/удобное
> времяУгу. И в результате получается оффлайн-апдейт :)
> а вообще это обычный трейдофф. Например, в случае стопки
> хостов может быть куда проще обкатать обновление на стенде и даже
> если не предусмотрены средства автоматического перезапуска нужного -- написать скрипт/рецепт
> для своего случая.Обычный. Но тут уже больше философский вопрос, хотим ли мы облегчить жизнь кому-то без стендов, или их проблемы.
> Так что продолжаю морщиться от того, как шляпники переваливают на юзеров свои
> проблемы, не желая их _решать_. К ним точно никто из
> некрософта не переходил? :(Насчет переходов не в курсе, но почему свои-то? Проблема вроде общая.
>> В настолько общем -- тогда уж и со штатным ребутом в контролируемое/удобное
>> время
> Угу. И в результате получается оффлайн-апдейт :)Ну да. Но только потому, что решать задачу иначе - вы отказались. Как и федорино горе...
> Насчет переходов не в курсе, но почему свои-то? Проблема вроде общая.
Потому что это проблема мейнтейнеров. Вам показали, что эту проблему можно успешно решать, показали как это делают в других дистрибутивах.
> Ну да. Но только потому, что решать задачу иначе - вы
> отказались. Как и федорино горе...Врать только не надо, пожалуйста. Как я бы её решал, мне кажется, описал уже достаточно. Это вам всё что-то не нравится.
> Потому что это проблема мейнтейнеров. Вам показали, что эту проблему можно
> успешно решать, показали как это делают в других дистрибутивах.Вы неплохой демагог (это комплимент, не подумайте). Мне как минимум два бага показали, прямо связанные с этой "успешностью".
>> Ну да. Но только потому, что решать задачу иначе - вы
>> отказались. Как и федорино горе...
> Врать только не надо, пожалуйста. Как я бы её решал, мне кажется,
> описал уже достаточно."Перезапустить все нафиг" - не решение. Просто вы замели проблему под ковер, как и федоровцы.
>> Потому что это проблема мейнтейнеров. Вам показали, что эту проблему можно
>> успешно решать, показали как это делают в других дистрибутивах.
> Мне как минимум два бага показали, прямо связанные с этой "успешностью".Но вы показали только один. Более того, он был закрыт в testing/sid. В чем, собственно, проблема?
> "Перезапустить все нафиг" - не решение. Просто вы замели проблему под
> ковер, как и федоровцы.
> Но вы показали только один. Более того, он был закрыт в
> testing/sid. В чем, собственно, проблема?Выше писал, это не всё. И если вам больше нравится открывать-закрывать баги с живой системы, вместо однократного решения, то ничего больше посоветовать не могу. Если это под ковер, то ваш вариант это обеспечивать чистоту подметанием там, где уже грязно.
>> "Перезапустить все нафиг" - не решение. Просто вы замели проблему под
>> ковер, как и федоровцы.
>> Но вы показали только один. Более того, он был закрыт в
>> testing/sid. В чем, собственно, проблема?
> Выше писал, это не всё.Не знаю что вы там "писали", но в качестве примера привели ровно один баг.
> И если вам больше нравится открывать-закрывать баги
На то и тестинг. И в отличие от вас, я живу в реальном мире.
> вместо однократного решения
"Однократное решиение" в виде "перезапустить все нафиг" - меня не устраивает. Ибо *уже есть* - лучшее.
Хотите его автоматизировать - флаг в руки. Но пока ничего конкретного по этому поводу вы не предложили, увы.
>> В настолько общем -- тогда уж и со штатным ребутом в контролируемое/удобное время
> Угу. И в результате получается оффлайн-апдейт :)Я к тому, что это случай "оригинальное не ново, а новое не оригинально".
> Обычный. Но тут уже больше философский вопрос, хотим ли мы облегчить жизнь
> кому-то без стендов, или их проблемы.Да просто тщательнее надо. Как уже упоминалось и могу подтвердить, проблемы такого рода вообще-то затрагивают rolling release и обновления между дистрибутивами. Если кто-то настолько плюёт на своих пользователей, что вываливает на них такое в рамках жизненного цикла дистрибутива -- какой красивой бумажкой ни накрой, суть не изменится.
> Проблема вроде общая.
Упорно продолжаю не наблюдать в изрядно разных случаях на своих альтах. :)
> Я к тому, что это случай "оригинальное не ново, а новое не
> оригинально".А. Если только это, то /me не против :)
> Да просто тщательнее надо. Как уже упоминалось и могу подтвердить, проблемы
> такого рода вообще-то затрагивают rolling release и обновления между дистрибутивами.
> Если кто-то настолько плюёт на своих пользователей, что вываливает на них
> такое в рамках жизненного цикла дистрибутива -- какой красивой бумажкой ни
> накрой, суть не изменится.Такое это про апдейт на несовместимую по ABI версию библиотеки?
У меня есть смутные сомненья, что корни проблемы ограничиваются только этим. У упомянутого dlopen() есть всякие интересные флаги... Может попробую как-нибудь слепить проблемный кейс. Хотя не факт что его итоговая правильность выйдет что-то доказывающей.>> Проблема вроде общая.
> Упорно продолжаю не наблюдать в изрядно разных случаях на своих альтах. :)Я про возможность. Если мэйнтейнеры Альта или любого другого дистрибутива настолько квалифицированны, что не допускают ни единой подобной проблемы, то честь им и хвала. Но я бы предпочел иметь что-то кроме этого, на всякий пожарный. Переваливания там проблем или не переваливания, но любой некоммерческий дистрибутив формально ведь ничего такого своим пользователям не обещает (и правильно делает). Если это мой локалхост, то фиг с ним, но если нет, то перестраховываться имхо разумно.
> Такое это про апдейт на несовместимую по ABI версию библиотеки?IIRC там сложнее -- лучше у ldv@ спросить, чтоб я не переврал.
> Но я бы предпочел иметь что-то кроме этого, на всякий пожарный.
> Переваливания там проблем или не переваливания, но любой некоммерческий дистрибутив
> формально ведь ничего такого своим пользователям не обещает (и правильно делает).Ну здесь всё-таки не только некоммерческий вариант возможен, хотя и силы на багфиксы куда ограниченней, чем у шляпы (хотя... для любой конкретной проблемы в итоге важны не абсолютные величины возможных сил/фич, а хватило или нет выделенных).
> IIRC там сложнее -- лучше у ldv@ спросить, чтоб я не переврал.Тоже так кажется, иначе в той же дебиановской спрашивалке нет особого смысла. Разве что она в стейбле отсутствует.
> силы на багфиксы куда ограниченней, чем у шляпы
> (хотя... для любой конкретной проблемы
> в итоге важны не абсолютные величины возможных сил/фич, а хватило или
> нет выделенных)Дык угу. Объем задач, грубо говоря, одинаковый (количество пакетов и выполняемые задачи для дистрибутивов общего назначения), а человеческие ресурсы разнятся сильно. Учитывая вышесказанное о заведомом отсутствии гарантий, мэйнтейнеры некоммерческих вариантов имеют все права на определенные неидеальности, им и так за это не платят. Тогда иметь какую-то автоматизацию для подстраховки вещь полезная.
В сумме, с одной стороны можно конечно обвинять людей в некачественном выполнении своих задач с перекладыванием части решений на пользователей, и быть на первый взгляд правым... Но имхо это неправильно.
>> ну все - ждем fedora 18 pro/rt итд
> Ждем комментаторов, которые понимают что по-старому все равно изменения вступали в силу
> в основном после перезагрузки. А до неё могли быть забавные ошибки
> у приложений, которые обновились, будучи запущенными.Для чего у взрослых - эти самые приложения перезапускались после обновления, при необходимости. С той же glibc так в debian сделано.
> Плюс возможность обновляться на лету как бы не удаляют:
>> Note that this feature does not prevent you from using yum and other commandline tools to install updates whenever you want to."Как-бы" нафиг такое "не удаление" сдалось. Вы действительно не понимаете разницы?
Толку от такой "установки" до перезагрузки системы не будет ровно никакой.
> Для чего у взрослых - эти самые приложения перезапускались после обновления, при
> необходимости. С той же glibc так в debian сделано.Взрослые сами решают, когда им удобнее перезапустить софт. И самый удобный вариант — на следующем старте системы, по крайней мере для тех, кто её регулярно перезагружает.
> "Как-бы" нафиг такое "не удаление" сдалось. Вы действительно не понимаете разницы?
Я понимаю, что это всё во-первых добавление функциональности, а не изменение или удаление, во-вторых для юзеров гнома и обновлятора в packagekit. Вот чего не понимаю, так это кипиша по этому поводу. Впрочем, в какой-то мере традиционного.
> Толку от такой "установки" до перезагрузки системы не будет ровно никакой.
Ну не тыкайте на эту кнопку, если вам нужен немедленный толк, г-ди. Будет особенно смешно, если там прямо рядом будет такая же для немедленной установки, как обычно.
Но даже если не будет, в данном случае не страшно. Лично для меня при наличии консольного yum это все равно лишние сущности.В очередной раз можно убедиться, насколько это благодарное дело, пытаться что-то делать для других. Hint: мнение о "чем-то" можно держать при себе, оно очевидно.
>> Для чего у взрослых - эти самые приложения перезапускались после обновления, при
>> необходимости. С той же glibc так в debian сделано.
> Взрослые сами решают, когда им удобнее перезапустить софт.Это *сейчас* так (и то, подозреваю что в федоре с этим горе, как обычно...)
> И самый удобный вариант
> — на следующем старте системы, по крайней мере для тех, кто
> её регулярно перезагружает.И где тут "удобство", и что тут вообще можно "решать" - выбора-то у вас нема будет. Понятно, нет?
>> "Как-бы" нафиг такое "не удаление" сдалось. Вы действительно не понимаете разницы?
> Я понимаю, что это всё во-первых добавление функциональности, а не изменениеПардон, вы вообще поняли что изменилось? О каком добавлении речь, сударь? Все как обычно: было, до ума довести не сумели - решили поломать нафиг и сделать дешево и сердито...
> удаление, во-вторых для юзеров гнома и обновлятора в packagekit.
Там речь с дальним прицелом - на всякие glibc и проч. Что аукнется далеко не хомячкам в первую очередь...
>> Толку от такой "установки" до перезагрузки системы не будет ровно никакой.
> Ну не тыкайте на эту кнопку, если вам нужен немедленный толк, г-ди.И какой толк от "установки" заплатки, которая на самом деле не установлена, не работает?
> Это *сейчас* так (и то, подозреваю что в федоре с этим горе,
> как обычно...)Окажите услугу, не воюйте с подозрениями.
> И где тут "удобство"
Удобство в том, что самый недеструктивный метод применяется с минимумом усилий. Можете тоже обвинять в канцелярщине :)
> и что тут вообще можно "решать" - выбора-то
> у вас нема будет. Понятно, нет?Нате еще раз, мне копипастить не сложно:
> Note that this feature does not prevent you from using yum and other commandline tools to install updates whenever you want to.
> Also note that this feature is about implementing offline updates for GNOME. Other spins are not affectedЕдинственный пункт, где _возможно_ не будет выбора (вы же в глаза фичу не видели и не собираетесь, правильно понимаю?) — возможность обновить системный компонент на лету. В gnome-packagekit. Всё?
> Пардон, вы вообще поняли что изменилось? О каком добавлении речь, сударь?
> Все как обычно: было, до ума довести не сумели -
> решили поломать нафиг и сделать дешево и сердито...Что понял уже описал не раз. От вас пока только негодование.
> Там речь с дальним прицелом - на всякие glibc и проч.
> Что аукнется далеко не хомячкам в первую очередь...А зачем далеконехомячкам paсkagekit вообще, не подскажете?
> И какой толк от "установки" заплатки, которая на самом деле не установлена,
> не работает?Опять 25. А yum -y update / apt-get upgrade это значит "работает"? Во всех случаях?
> Включение в дистрибутив поддержки обновления системы в offline-режиме
> ... например, glibc и других основных библиотек
> Переход на использование tmpfs для раздела /tmpПриплыли. "Будет круто" (ц), если эти фичи потом RHEL подхватит.
Манагеры ихние явно с катушек съехали и всерьез желают свою долю серверного рынка кому-то подарить...
> Реализация поддержки 256 цветов в терминале
Мда, Киллер-фича...
>> Переход на использование tmpfs для раздела /tmp
> Приплыли. "Будет круто" (ц), если эти фичи потом RHEL подхватит.
> Манагеры ихние явно с катушек съехали и всерьез желают свою долю серверного
> рынка кому-то подарить...Использую в альте уже лет пять, доволен.
> Использую в альте уже лет пять, доволен.Почитайте дебиановскую рассылку. Народ совсем недавно обсуждал и сошлись на том, что это глупость как дефолт по целой куче причин.
> Почитайте дебиановскую рассылку. Народ совсем недавно обсуждал и сошлись на том,
> что это глупость как дефолт по целой куче причин.Хипстеры, что с них взять. Главный аргумент против чего-то - так делает редхат. И пофигу, что ядро и окружение дебиана в редхате сделаны.
> И пофигу, что ядро и окружение дебиана в редхате сделаны.http://www.debian.org/ports/hurd/
http://www.debian.org/ports/kfreebsd-gnu/Debian не нуждается в поделках RH
> Debian не нуждается в поделках RHВот когда они Linux kernel выкинут, тогда и поговорим.
А пока - не просто нуждаются, но и зависят.
> Вот когда они Linux kernel выкинут, тогда и поговорим.У вас Red Hat головного мозга.
http://www.opennet.me/opennews/art.shtml?num=33529Вклад в ядра 2.6.36-3.2.0:
Энтузиасты - 16.2%
Red Hat- 10.7%Тот же Google по совокупности опередит RH, если приплюсовать вклад Samsung, Freescale, TI, Broadcom, ST Ericsson, Linaro - потому что они есть в рейтинге только благодаря платформе Android.
> Тот же Google по совокупности опередит RH, если приплюсовать вклад Samsung, Freescale,
> TI, Broadcom, ST Ericsson, Linaro - потому что они есть в
> рейтинге только благодаря платформе Android.У гнусмаса Bada ж ещё была?
> У гнусмаса Bada ж ещё была?Ну 0,5% можно на баду списать :) но например Pengutronix заниамется продвижением кастомизированных ядер Freescale в ванильное ядро, а у него 1% :)
>> Debian не нуждается в поделках RH
> Вот когда они Linux kernel выкинут, тогда и поговорим.А что, RH сделала ядро Linux? Вас Леннарт покусал?
> И пофигу, что ядро и окружение дебиана в редхате сделаны.Это, мягко говоря, неправда.
> Почитайте дебиановскую рассылку. Народ совсем недавно обсуждал и сошлись на том,
> что это глупость как дефолт по целой куче причин.Правильно, так внедрение этой фичи в федору - это не включение галочки. Это большая работа по вычищению всех косяков, которые раньше мешали это использовать. И они ее сделали и могут включить по дефолту (с возможностью легкого отключения для тру-админов).
> Правильно, так внедрение этой фичи в федору - это не включение галочки.
> Это большая работа по вычищению всех косяков, которые раньше мешали это
> использовать.А можно несколько примеров таких косяков? (Это не попытка возразить, а чистое любопытство.)
>> Правильно, так внедрение этой фичи в федору - это не включение галочки.
>> Это большая работа по вычищению всех косяков, которые раньше мешали это
>> использовать.
> А можно несколько примеров таких косяков? (Это не попытка возразить, а чистое
> любопытство.)https://bugzilla.redhat.com/show_bug.cgi?id=858265
https://bugzilla.redhat.com/show_bug.cgi?id=827581
https://bugzilla.redhat.com/show_bug.cgi?id=858264
https://bugzilla.redhat.com/show_bug.cgi?id=858266
http://0pointer.de/blog/projects/tmp.html
> это глупость как дефолт по целой куче причин.Ну приводите эти причины. Только, чур, те, которые сами абсурдными не считаете.
У меня /tmp на tmpfs, но дефолтом может быть неудобно если свободной памяти в системе немного, а временный файл большой / их много. Из-за этого, кстати, TMPDIR для FF в /var/tmp перенесли, изчанально даже без возможности оверрайда.
Пункт №3. Здравствуй система обновлений Windows™ ®
про "племенное мышление" читать тут -- http://www.opennet.me/opennews/art.shtml?num=27490
> Пункт №3. Здравствуй система обновлений Windows™ ®В UNIX, afaik, такая система обновлений нареканий не вызвала. Например, LiveUpgrade в Solaris.
> В UNIX, afaik, такая система обновлений нареканий не вызвала. Например, LiveUpgrade в Solaris.Впрочем, бессмысленно говорить по UNIX с тем, кто знает только винду и убунту.
А где можно новый упрощенный интерфейс анаконды глянуть ? Или это сюрприз, на вроде жмешь поставить офис, видео или графика и он сам ставит необходимые пакеты, которые они сочтут нужными ?)
Скажите Федора по-прежнему требует 768 метров оперативки для установки? Если да то не нужна, в принципе...
> Скажите Федора по-прежнему требует 768 метров оперативки для установки? Если да то
> не нужна, в принципе...Конечно нет, теперь это 1 ГБ
> Скажите Федора по-прежнему требует 768 метров оперативки для установки? Если да то
> не нужна, в принципе...весьма спорно!
у меня 8G на ноутбуке. мне кажется Fedora нужна.
А netinstall у них существует?
Существует. Сам ставил им 2 системы.
http://dl.fedoraproject.org/pub/fedora/linux/releases/test/1...
> Включение по умолчанию сервиса Avahi (открытая реализация Zeroconf) при установке десктопа, что позволит задействовать функциональность автоматического определения открытых для совместного доступа MDNS устройств и, в частности, принтеров;Тоже мне новость. Будто в прошлых выпусках он был выключен.
Интересно, а почему размер образа 786 Мб, а не 650, как у них обычно? Придётся снова искать CD-R 800 Mb, которых уже нигде не купить, как для Ubuntu? А хотелось просто воспользоваться CD-RW.
>Переход на использование tmpfs для раздела /tmpУ меня в слаке оно появилось после того, как задолбался чистить этот самый /tmp. ЧЯДНТ?
> У меня в слаке оно появилось после того, как задолбался чистить этот самый /tmp. ЧЯДНТ?Use systemd, Luke. Там есть демон, который автоматически чистит /tmp.
> Там есть демон, который автоматически чистит /tmp.Хотя, конечно, это ненужный велосипед. Зачем что-то делать автоматически, если это можно сделать вручную?
Зачем что-то делать вручную, если то же можно сделать автоматически?
> Зачем что-то делать вручную, если то же можно сделать автоматически?Не slackware-way это.
>Зачем что-то делать вручную, если то же можно сделать автоматически?Зачем что-то делать вручную или автоматически, если это самое /tmp у меня в слаке и так пустое после перезагрузки/выключения?
ЗЫ: Разбираться почему - лень.
> Зачем что-то делать вручную или автоматически, если это самое /tmp у меня
> в слаке и так пустое после перезагрузки/выключения?У кого-то пустое /tmp, кто-то задолбался его чистить... Слака полна неожиданностей!
> Use systemd, Luke. Там есть демон, который автоматически чистит /tmp.с каких пор для этого нужен systemd????
> с каких пор для этого нужен systemd????Да, можно и без systemd - изобрести собственный велосипед, на костылях скриптов. Правда, нормального age control там не будет, но это уже мелочи.
> Да, можно и без systemd - изобрести собственный велосипед, на костылях скриптов.Становится понятно, почему у Поттеринга вообще есть сторонники. Такой сложный скрипт (максимум строчки 3, я думаю) + cron или 20 секунд гугления (если лень набирать) - это же ужас какой "костыль на скриптах"! Причем все это доступно чуть ли не с начала времен (компьютерных), так что велосипед-то тут кое-кто другой изобретает.
> Такой сложный скрипт (максимум строчки 3, я думаю) + cron или 20 секунд гугления (если лень набирать)Очень хотелось бы посмотреть, как в этих трех строчках осуществляется контроль возраста файлов (времени с момента их последнего использования) и его сравнение с конфигом. Поделитесь, будьте добры!
> Очень хотелось бы посмотреть, как в этих трех строчках осуществляется контроль возраста
> файлов (времени с момента их последнего использования) и его сравнение с
> конфигом. Поделитесь, будьте добры!Хотя... если каждая из этих строчек начинается с perl -e и содержит по полстраницы кода в стиле $??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see...
то это отличное доказательство простоты и прозрачности shell-скриптов, разумеется.
>> Такой сложный скрипт (максимум строчки 3, я думаю) + cron или 20 секунд гугления (если лень набирать)
> Очень хотелось бы посмотреть, как в этих трех строчках осуществляется контроль возраста
> файлов (времени с момента их последнего использования) и его сравнение с
> конфигом. Поделитесь, будьте добры!find /tmp/ -atime $ATIME -type f
> find /tmp/ -atime $ATIME -type fЛучше тогда stmpclean из альта позаимствовать.
>> с каких пор для этого нужен systemd????
> Да, можно и без systemd - изобрести собственный велосипед, на костылях скриптов.
> Правда, нормального age control там не будет, но это уже мелочи.Какой еще age control? Как у systemd, на уровне find -atime? Да не смешите мои тапочки.
Другое дело, что речь шла о переходе на tmpfs - видать у бойца каталог /tmp не очищался при перезагрузке. А это уже проблема скриптов дистрибутива.
> Use systemd, ... . Там есть демон, который автоматически чистит /tmp.А не пошел бы он этот systemd ... , лесом:
$ apt-cache search tmp |grep clean
stmpclean - A safe temporary directory cleaner
> А не пошел бы он этот systemd ... , лесом:
> $ apt-cache search tmp |grep clean
> stmpclean - A safe temporary directory cleanerКакие-то у вас уж очень местечковые поделки:
http://packages.debian.org/search?keywords=stmpclean
http://packages.ubuntu.com/search?keywords=stmpclean
Вы искали пакеты, в именах которых есть stmpclean. Были просмотрены все комплекты, все секции и все архитектуры.
Ничего не найдено
>> stmpclean - A safe temporary directory cleaner
> Какие-то у вас уж очень местечковые поделки:
> http://packages.debian.org/search?keywords=stmpclean
> http://packages.ubuntu.com/search?keywords=stmpclean:)
Я вас умоляю, да используйте хоть TMPTIME, хоть однострочник (на вкус и цвет же), только без катерпиллера под названием systemd, на котором предлагают съездить за спичками.> местечковые
А что под этим имелось в виду, и с каких пор в opensource появились термины, местечковое, твоё, моё?
Напуркуа он тогда этот опенсорс сдался?
Ять! Что они сделали с анакондой? Был же простой и понятный интерфейс, а сейчас непойми что.
А KDE то в новой Федоре какое красивое, фичастое и надо сказать быстрое оказывается на Core i3 со встроенной Intel графикой!
про teaming можно ли где почитать на русском и может уже есть практика использования - как оно на деле то ?