Лиэнн Огасавара (Leann Ogasawara), менеджер команды поддержки ядра в компании Canonical, рассказала (http://www.extremetech.com/computing/146442-canonical-might-...) в рамках семинара Google Hangouts (см. 42 минуту видеорозаписи (http://www.youtube.com/watch?v=AQvOIExkCaw)) о рассмотрении возможности перехода к новой модели разработки, при которой классические обособленные выпуски будут формироваться только для LTS-релизов, а вместо промежуточных версий будет доступен непрерывно обновляемый Rolling-репозиторий. Используя данный репозиторий, пользователи будут иметь возможность установки в LTS-выпуске последних версии программ без ожидания формирования очередного релиза дистрибутива. По словам Лиэнн, Canonical может перейти к новой модели не раньше, чем после выпуска весной следующего года очередного LTS-релиза 14.04.
Таким образом, предлагается выпускать отдельные релизы Ubuntu раз в два года, а в промежутки между LTS-выпусками прекратить формирование раз в 6 месяцев обособленных релизов. Предлагаемый подход позволит сохранить стабильность LTS-выпусков и доступность инноваций промежуточных версий, при этом пользователям не придётся ждать отдельных релизов при желании использования новых версий программ, а компания Canonical сможет не тратить лишние ресурсы на поддержку каждого промежуточного выпуска в течение 18 месяцев. LTS-релизы будут формироваться как стабилизированный срез Rolling-репозитория, для которого по мнению Canonical можно обеспечить высокий уровень качества и стабильности.
По словам Лиэнн поддержание rolling-репозитория в стабильном состоянии большая, но выполнимая задача. Подобный репозиторий должен быть постоянно в целостном состоянии, все доступные пакеты должны всегда быть работоспособными и сочетаться друг с другом. В настоящее время при разработке Ubuntu уже практикуются некоторые методы ежедневного контроля качества, производится автоматизированное тестирования работоспособности сборок.Тем не менее, обсуждаемое нововведение выглядит нереалистично с учётом возможности негативного влияния на пользователей, которым недостаточно релиза раз в два года и возможности использования rolling-выпусков в остальное время. При rolling-выпусках теряется возможность контроля за появлением инноваций, пользователь обычного релиза имеет возможность решить переходить сразу на новый выпуск или подождать какое-то время. Rolling-выпуски непредсказуемы для пользователя, нововведения могут обрушиться в неожиданные и неподходящие моменты. Кроме того, невзирая на все усилия по стабилизации и тестирования, rolling-выпуски по своей сути менее стабильны, чем обычные релизы (особенно с учётом того, что многие пользователи не устанавливают релиз сразу, а выжидают примерно месяц, за который успевают устранить вовремя не выявленные ошибки).
<center><iframe width="640" height="360" src="http://www.youtube.com/embed/AQvOIExkCaw?rel=0" frameborder="0" allowfullscreen></iframe></center>URL: http://arstechnica.com/information-technology/2013/01/ubuntu.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=35901
>не раньше, чем после выпуска весной следующего года очередного LTS-релиза 14.04.Спасибо, не надо.
надо.
но возможно это слишком поздно.
Еще как надо - это правильный ход. Никаких LTS и не LTS - просто уровень обновлений сам себе в систме ставишь - или только стабильные релизы пакетов накатывать, или ночные билды - решать тебе как админу/пользователю. А жестко связывать по рукам на уровне дистра - это было плохой идеей, но возможно хорошим маркетингом в начале.
а мне кажется очень логичным и удобным. Я за
Rolling для десктопа это правильно.
> Rolling для десктопа это правильно.Плюсую.
Лучше сделать как в Debian — опциональный rolling-release.
насколько я понял так и есть.
>вместо промежуточных версий будет доступен непрерывно обновляемый Rolling-репозиторий.для тех кому стабильность важнее функциональности, тот продолжает использовать LTS и НЕ использовать эту репу.
В Debian это всё ужасно сделано и для использования вообще не предназначено, а только для тестирования самими разработчиками: обновления на сотни мегабайт каждый день, включающие в основном интеграционные патчи, низкая стабильность, тотальная забагованность...
Толсто. Тестинг дебиана юзабельнее релизов убунты и федоры вместе взятых.
Только testing замораживается, поэтому он не rolling. Речь об unstable, на базе которого ubuntu и собирается.
unstable стабильнее
experimental
Че уж там
> experimental
> Че уж тамУчите мат. часть.
Древнее софт, и к тому же тупо не обновляемый не есть синоним "юзабельнее". Если просто программа лежит, она от этого не улучшается сама собой.
> Лучше сделать как в Debian — опциональный rolling-release.В дебиане это очень криво сделано: вы или жрете окаменелый крап или камикадзите по минному полю где могут факапнуть все. Вплоть до слета загрузчика.
В Debian больше чем два варианта :) stable, testing, unstable, experimental, и есть ещё security updates и будущие обновления :)
>> Лучше сделать как в Debian — опциональный rolling-release.
> вы или жрете окаменелый крапБудто плохое.
Не все пользователи - арчешкольники, которым подавай новую версию софта исключительно ради новой версии.
inb4 обновления безопасности: все патчи, связанные с безопасностью, бэкпортируются в stable.
у Debian есть Backports
честно, серьёзная заявка на замену моей генты.
но пока…
На замену арча. До генту как до Китая.
> На замену арча. До генту как до Китая.Сразу после появления аналога aur (ppa - не то)
Я уже давно перешёл с геты на убунту, а теперь рассматриваю возможности перехода обратно.
Что бы потом рассматривать возможность перехода на убунту?
Променад?
Калька. Бинарный роллинг с добором из портежей из сырцов того что-интересно-только-тебе. Для хомячков не готов только красивый обновлятор - остальное лучше чем в бубунте.
осталось LTS синхронизировать со стабильными выпусками Debian...
просто отличная новость, жаль что так нескоро!
> просто отличная новость, жаль что так нескоро!Почитай opennet за прошлые годы, посмотри как много обещаний Canonical сбылось. Они просто пиарятся большим количеством бессодержательных новостей, такой у них маркетинг. Полезных новостей среди этого множества мало.
Кстати, а они случаем не в 12.10 обещали сделать дефолтным браузером Хромиум?
Ну что, еще 3-4 года и пойдет дело!
Станут как Debian по сути. Только выпуски не when it's done, а по времени.
Какая миловидная восточная внешность у менеджера команды поддержки ядра.
>восточная внешность
>OgasawaraДумаю, она неспециально
Не потянут. Будет мощнейший глюкодром, с которого все сразу убегут на нормальные дистры.
А ведь я давно об этом говорил. Ну ничего, сделаю поправку на свой русский.
Главное чтобы на стабильность не отражалось. А то только отгонят потенциальных корпоративных клиентов которым нужна прежде всего стабильность работы, а не погоня за новыми фишками и версиями.
лтс то останется лтс'ом.
Так для их есть и будет LTS, а для десктопа лучше rolling. Почти всегда на таком и сижу, при этом проблемы бывают только с Unity, которым не пользуюсь. Raring так вообще очень плавно идет и обновлений очень мало, на LTS 12.04 их и то больше было :)
> Почти всегда на таком и сижу, при этом проблемы бывают только с Unity, которым не пользуюсь.очень смешно
Во FreeBSD давно так.
Это только для стабле-каррента. У релизов дискретный и нерегулярный патч-левел.
Патч-левел здесь ни при чём — он из другой области.Непрерывное обновление портов и централизованнная сборка бинарных пакетов поддерживаются прежде всего для -STABLE (для -CURRENT — как получится) версии операционной системы, а это уже rolling-модель обновлений портов и базовой системы.
-RELEASE получаются из среза -STABLE и к нему поставляется замороженное дерева портов и подготовленная куча бинарных пакетов на определённый момент среза. Тут уж как повезёт: бывает сразу после релиза критические обновление каких-либо ключевых библиотек типа libjpeg, libpng. Если порты/пакеты обновлять в уже выпущенном релизе, то разработчики не гарантируют такую же стабильность, как у протестированных бинарных пакетов в релизе.
> -RELEASE получаются из среза -STABLE и к нему поставляется
> замороженное дерева портов и подготовленная куча бинарных
> пакетов на определённый момент среза.Вы ошибаетесь. То, что поставляется в комплекте релиза - это никакое не мороженое дерево. Это просто дерево портов по состоянию на момент выпуска релиза. Оно ничем не отличается концептуально от дерева месяцем раньше или месяцем позже. Какое было - такое и впиндюрили в релиз.
Раньше, по диалапу, поставить штатное дерево релиза и портснапом заапдейтить его было ЗАМЕТНО быстрее, чем тянуть все дерево с нуля. Ну, а сейчас, при гигабитных каналах, в поставке дерева в релизе смысла вообще нет. Потому, собсно, и начали выпускать фрю в виде образа для флешки.То же касается пакаджей. Если раньше в пакаджах на диске были мох и болото, включая сквид и мц, то щас там хорошо, если иксы положат, с каким-нить КДЕ.
Ровно то же касается и сырцов, которые сейчас в релизный образ включают из чисто сентиментальных соображений.
У фри порты роллятся с гранулярностью в час. Во всяком случае - портснап не шевелится, если текущее состояние дерева портов устарело менее, чем на час. Пакаджи, емнип, билдятся раз в сутки. И есть еще обновления ядра и юзерленда, которые выкатываются нерегулярно в виде патч-левелов, и при этом не превращают RELEASE в STABLE или CURRENT.
>[оверквотинг удален]
> То же касается пакаджей. Если раньше в пакаджах на диске были мох
> и болото, включая сквид и мц, то щас там хорошо, если
> иксы положат, с каким-нить КДЕ.
> Ровно то же касается и сырцов, которые сейчас в релизный образ включают
> из чисто сентиментальных соображений.
> У фри порты роллятся с гранулярностью в час. Во всяком случае -
> портснап не шевелится, если текущее состояние дерева портов устарело менее, чем
> на час. Пакаджи, емнип, билдятся раз в сутки. И есть еще
> обновления ядра и юзерленда, которые выкатываются нерегулярно в виде патч-левелов, и
> при этом не превращают RELEASE в STABLE или CURRENT.Зачем вы это мне говорите?
% uname -a
FreeBSD roxy.fire 9.1-STABLE FreeBSD 9.1-STABLE #0 r245741: Mon Jan 21 18:27:51 VOLT 2013 root@roxy.fire:/usr/obj/usr/src/sys/ROXY amd64
> Зачем вы это мне говорите?Ну просто чтобы люди не думали, будто бы в релизах фрей заморожены порты и пакаджи. А то потом придется долго и нудно объяснять, что в жизни все не так, как на самом деле...
>> Зачем вы это мне говорите?
> Ну просто чтобы люди не думали, будто бы в релизах фрей заморожены
> порты и пакаджи. А то потом придется долго и нудно объяснять,
> что в жизни все не так, как на самом деле...Попробуй поставь обновленные пакеты на релиз. Без компиляци исходников из обновлённого дерева портов ничего не выйдет.
> Попробуй поставь обновленные пакеты на релиз. Без компиляци исходников из обновлённого дерева портов ничего не выйдет.да ладно. пакеты можно ставить когда угодно и куда угодно, хоть на релиз, хоть на предыдущий/следующий релиз и независимо от портов (на то и пакеты). Это вы уже за"portupgrade"ились.
Если бы было нельзя, то:
1) был бы эпик фейл пакетов вообще
2) для любого пакета нужно было бы проверять (?) на релиз он ставится или нет и есть ли порт и совпадает ли его версия с версией на дату релиза (???), что уже само по себе бредятина.
Если ставишь пакет на другую версию (скажем пакет от 9.1 на 9.0) то выдаст warning и, если ничто не мешает поставиться, то поставится. Но наличие и версия портов никак не влияет на установку пакета.
> Попробуй поставь обновленные пакеты на релиз. Без компиляци исходников из обновлённого
> дерева портов ничего не выйдет.
# portsnap fetch update
# portmaster -Pta
ЧЯДНТ?
>> Попробуй поставь обновленные пакеты на релиз. Без компиляци исходников из обновлённого
>> дерева портов ничего не выйдет.
># portsnap fetch update
> # portmaster -Pta
> ЧЯДНТ?Используешь сторонний инструмент совместно с обновлённым деревом портов на релизе? Это по большому счёту хак, так как актуальное дерево портов прежде всего для -STABLE.
А вот стандартная команда "pkg_add -r имя_нужного_пакета" установит только пакет и его зависимости, собранные для релиза (который может быть вышел несколько лет назад :D ). В то же время та же команда в -STABLE установит пакет последней доступной версии для этой ветки ОС, не обращаясь к дереву портов.
> Используешь сторонний инструментДа. Так уж сложилось исторически, что я, преимущественно, пользуюсь сторонними инструментами. Я использую gcc, чтобы не набивать бинарный код вручную, я использую exim, чтобы не вручную принимать, обрабатывать и отправлять почту, и я использую portmaster, настоятельно рекомендуемый официальным хендбуком FreeBSD, чтобы не вручную шаманить с деревом портов, зависимостями и pkg_*.
> Это по большому счёту хак, так как актуальное дерево портов прежде всего для -STABLE.
Вы ошибаетесь. Актуальное дерево портов, прежде всего - для FreeBSD. Для всех ее версий и веток. Только в случае альтернативно одаренных авторов сторонних софтов, которые жестко привязываются к фичам той или иной версии, в мейкфайле порта может появиться нечто, вроде:
.if ${OSVERSION} < 800000
BROKEN= does not compile on FreeBSD 7.x
.endif
> А вот стандартная команда "pkg_add -r имя_нужного_пакета" установит только пакет и его
> зависимости, собранные для релиза (который может быть вышел несколько лет назадЕсли не обновлять дерево портов - да. Но если не обновлять сырцы и не трогать конфиг ядра, то buildworld ТОЖЕ будет собирать все тот же релизный генерик. И что?
Снова пытаюсь намекнуть, что штатная утилитка freebsd-update обновляет бинарное ядро, модули, бинарники юзерленда и исходники системы, не отменяя статуса релиза для полученного продукта.
uname -a
FreeBSD ХХХ.ХХХХ.ХХ 7.3-RELEASE-p4 FreeBSD...
> Снова пытаюсь намекнуть, что штатная утилитка freebsd-update обновляет бинарное ядро,
> модули, бинарники юзерленда и исходники системы, не отменяя статуса релиза для
> полученного продукта.Капитан Очевидность, что ли?
>> А вот стандартная команда "pkg_add -r имя_нужного_пакета" установит только пакет и его
>> зависимости, собранные для релиза (который может быть вышел несколько лет назад
> Если не обновлять дерево портов - да.Если обновить в релизе или в патч-левеле дерево портов, то опять — ДА. Потому что "pkg_add -r packagename" не смотрит в дерево портов (его может и не быть, например, в embedded-железке x86, связь с которой по ssh), а берёт архивы бинарных пакетов из каталога
ftp://ftp.freebsd.org/pub/FreeBSD/releases/`uname -m`/X.Y-RELEASE/packages/
> "pkg_add -r packagename" не смотрит в дерево портовЭ, сорри, был неправ. Пакаджи действительно содержат внутри себя дерево зависимостей в файликах +REQUIRE и +REQUIRED_BY. Однако использование комплекта пакаджей, собранного при выпуске релиза, не является обязательным.
И это не отменяет того факта, что постоянно обновляемое дерево портов может (и должно) быть штатно использовано релизом FreeBSD, а не только стейблом или каррентом.
> Вы ошибаетесь. То, что поставляется в комплекте релиза - это никакое не мороженое дерево. Это просто дерево портов по состоянию на момент выпуска релиза. Оно ничем не отличается концептуально от дерева месяцем раньше или месяцем позже.Вообще-то отличается. Перед этим "просто срезом" делают ports freeze, аналогичному для src. Никаких особенных процедур, конечно, не делают, но в целом вероятность всякой хрени в релизном дереве ниже, чем в состояниях дерева в другой момент.
Ну наконец, главное сделать с умеренно новыми пакетами и все будет норм.
А что они будут делать в период заморозки Debian? Новые пакеты же брать неоткуда.
> А что они будут делать в период заморозки Debian? Новые пакеты же
> брать неоткуда.Самый лучший в мире дистрибутив Linux делает все пакеты сам. Это Debian тырит у него 90% пакетов.
>> А что они будут делать в период заморозки Debian? Новые пакеты же
>> брать неоткуда.
> Самый лучший в мире дистрибутив Linux делает все пакеты сам. Это Debian
> тырит у него 90% пакетов.Это сарказм или вы правда не в теме?
ну да...
тот же deluge 1.3.5 в precise появился, а для debian до сих пор не собран. fail
все правильно делают
Давно пора. На самом деле это единственный правильный подход к релизам.
> Canonical не исключает переход Ubuntu на rolling-обновленияЭто правильно, ящитаю. Всегда свежее ПО и отсутствие не всегда удачных обновлений с версии на версию.
>> Canonical не исключает переход Ubuntu на rolling-обновления
> Это правильно, ящитаю. Всегда свежее ПО и отсутствие не всегда удачных обновлений
> с версии на версию.Ты когда-нибудь обновлял системный libpng или libicu? А ворох компонентов GStreamer?
Обновлял libpng под последнюю степманию. Скачал с офсайта исходники последней версии, скомпилировал, собрал пакет, установил. Всё ок, всё работает. Precise Pangolin.
И частые глюки, а не только при обновлениях ).
учитывая качество 12.10, видать уже перешли тк это ИМХО ни разу не релиз, а
промежуточное состоянме между обновлениями. притом неудачное.по крайней мере десктопный вариант. Пришлось уйти на федору18.
Блин, а Алан Кокс в соседней новости совсем другое говорит. :)
> о *рассмотрении* возможности перехода ..."""
сообщаем Вам что сейчас Вам придёт уведомление, об предстоящем событии! ...
"""
Будущее за непрерывным обновлением. Некоторые наиболее продвинутые одмины всерьёз задумываются над тем, чтобы прописать "pacman -Syuf --noconfirm" в profile.rc
> Будущее за непрерывным обновлением. Некоторые наиболее продвинутые одмины всерьёз задумываются над тем, чтобы прописать "pacman -Syuf --noconfirm" в profile.rcа прикольная задумка! чтоб с работы не выгнали за бездеятельность!
На Debian'е что-ли хотят прописать? :)
> Будущее за непрерывным обновлением. Некоторые наиболее продвинутые одминыЛокалхоста?
>продвинутые одмины
>pacman -SyufНе смешно.
> Будущее за непрерывным обновлением. Некоторые наиболее продвинутые одмины всерьёз задумываются
> над тем, чтобы прописать "pacman -Syuf --noconfirm" в profile.rcПродвинутые в вашем понимании - те, кто сидят на нестабильном дистрибутиве и не смотрят чего обновляют?
Лучше пусть как было так и будет. Зачем портить фен-шуй? Вот няшка китаянка все правильно говорит. Довольно проблематично выходит.
> няшка китаянкакто это?
# P.S.: я конешно же понимаю что там все тян в китае -- няшки ^_^ . но всёже интересно знать кто из них ещё и говорит про Линуксы :-)
>> няшка китаянка
> кто это?
> # P.S.: я конешно же понимаю что там все тян в китае
> -- няшки ^_^ .Я один не понял о чём речь?
тыб хоть кукцю-нибудь Аниме для общего развития посмотрел бы чтоле...
Ogasawara - древняя китайская фамилия. Да.
> Ogasawara - древняя китайская фамилия. Да.так это же ононимный аналитег с самого опеннета
Я категорически против. Если что, уйду на Дебиан ).
> Я категорически против. Если что, уйду на Дебиан ).Угу, где то же самое, только иначе называется.
Давно пора. Наплодят релизов то.. LTS - рулят. И простым юзверям привычней. Им частая смена картинки кроме раздражения как правило ничего не приносит. :)
Это все из-за того, что алфавит для заглавных букв скоро заканчивается ;)
Отличная идея!!! Скорее бы уже.
Я всё ровно не покину Arch, как бы бубунта под него не косила!
И какой у вас период налета на арче?
Помню свой опыт использования Arch в качестве домашней системы. Первый пол года был наполнен энтузиазмом, синхронизировался с RR раз в неделю, потом раз в месяц, затем раз в квартал с горем пополам и несколькими ошибками, а через пол года оттягивания не осилил догнать RR. Теперь у меня Ubuntu LTS.
Пусть че хотят делают, только LTS пусть не трогают, для серверов идеальное решение с хорошим сроком поддержки.
Давно пора.
предлагаю всем раздавать снапшот из git-а или чего у них там. все равно ж не работает как надо, а так хоть свежий будет.
Это тактика такая, ждем пока кто-нить откликнется и в какой-нить федоре замутят. Потом можно и себе "внедрить ноухау".