Ядро Linux 3.2 получило статус длительной поддержки (LTS)

Я использовал не так уж и долго ~3 месяца, за это время апи она сломали только 1 раз, некритично.

Голландам зачем-то такая возможность понадобилась.

Думаю лишней не будет, чтобы не патчить не собирающийся софт под новую версию библиотеки в экстренном порядке в процессе обновления, а также чтобы была возможность откатиться если что не удастся что-либо собрать в автомате.

Вот к примеру весь сценарий обновления системы и всех сценариев для приложений:

nixos-checkout

Запуск процесса сборки и с последующей попыткой переключиться:

nixos-rebuild switch

Если сборка прошла неудачно - ничего не сломается, просто переключение не произойдет на новые библиотеки и ПО.

tmps 50% от общего объема озу, своп в файл

... а яйца дверью зажимать не пробовал? Если у тебя контент tmpfs вытеснил нафиг всё в своп, чего ты ещё ожидал получить?

Сборка на tmpfs? С каким -j? Сколько памяти? Сколько свопа?

-j9, памяти 4 гб, своп 5 гб.

У тебя банальный thrashing, который является _штатным_ поведением системы с виртуальной памятью.

И, если ты не знал, в твоей OpenSUSE тоже бинарные пакеты.

Шелдон?

Винда не удачный пример. Пример Винды - пример не продуманности.

Здесь при переключениях можно выбрать нужное поколение в цепочке сборки - на котором мы точно знаете что у Вас все работало (При этом выводится и номер поколения и дата и время сборки).

В винде черт ногу сломит чтобы понять что там отображается в выборе. Да и не работает в винде эта фича как ожидается, т.е. фича такая есть, а результат - не 100% работоспособность после обновления, и откат имеющийся не в 100% срабатывает, что влечет необходимость переустановки Винды.

В NixOS 100% гарантия возможности отката на рабочую конфигурацию.

А ты сделай объем tmpfs в 30% объема RAM и потом расскажи нам о результатах.

То же и про основной репозиторий.

В этом случае Космонавту по голове настучат, а в случае левого репозитория и спрашивать не с кого.

См. выше. Ну и проверить контрольные суммы и патчи тебе никто не мешает.

Проверка контрольных сумм и даже подписей ничего не даст. Патчи проверять слишком сложно и долго.

И ещё раз - это не баг, это нормальное поведение несбалансированной инсталяции

А вот это уже можно считать багом. Наличие ЗУ с разной скоростью записи - нормальная ситуация, и система должна обрабатывать ее корректно: https://lwn.net/Articles/405076/ https://lwn.net/Articles/456904/

Патчи проверять слишком сложно и долго.

еще не забываем про то, что prog-x.y.z.orig.tar.gz может содержать далеко не оригинальный код :)

В этом случае Космонавту по голове настучат

Ему пофиг (он ничего не обещал), а тебе это уже не поможет.

Проверка контрольных сумм и даже подписей ничего не даст.

Она даст тебе гарантию, что тарболл - тот же, что опубликован разработчиками (если ты проверяешь это для своих бэкпортов %)).

Патчи проверять слишком сложно и долго.

Они часто тривиальные. Впрочем, за отмазку вполне подойдет.

Я использовал не так уж и долго ~3 месяца, за это время апи она сломали только 1 раз, некритично.

Я начинал со второй версии. В третьей они ломали конфиг чуть ли не каждый билд. Надоело.

В NixOS перезагружаться в процессе и после обновления не требуется, а Винда этого требует даже в процессе установки и обновления софта. В NixOS можно вообще не перегружаться - переключение само производится - без перезагрузки, а для большей надежности можно спокойно дождаться подходящего момента для перезагрузки. NixOS не будет маниакально напоминать, а то и за Вас делать перезагрузку, когда у Вас работает важная задача.

... а яйца дверью зажимать не пробовал?

Кому?

Если у тебя контент tmpfs вытеснил нафиг всё в своп, чего ты ещё ожидал получить?

Читайте внимательно, отключение swap решало проблему. Исходя из этого я делаю вывод, что ядро все еще неразумно работает.

У тебя банальный thrashing, который является _штатным_ поведением системы с виртуальной памятью.

Ну и какое вы предлагаете решение?

Ему пофиг (он ничего не обещал), а тебе это уже не поможет.

не обещал, но за вредоносный код в офрепе его вполне могут подвесить за яйца.

Она даст тебе гарантию, что тарболл - тот же, что опубликован разработчиками (если ты проверяешь это для своих бэкпортов %)).

То есть мне для каждой проги из ppa надо лезть на сайт разработчиков чтобы сверить md5sum prog-x.y.z.orig.tar.gz с md5sum prog-x.y.z.tar.gz, опубликованным на сайте разработчика?

Люблю я FreeBSD, Gentoo и NixOS - за то что они не софт собирают в сборники, а сценарии сборки, а в сценариях ссылки на загрузку с авторских сайтов и контрольные суммы хранятся. По этим ссылкам загрузка производится и проверка сумм. Надежно как в танке.

У тебя банальный thrashing, который является _штатным_ поведением системы с виртуальной памятью.

Ну и какое вы предлагаете решение?

Я бы тупо отключил tmpfs и увеличил swap. Возможно, еще бы уменьшил -j.

P.S. использование tmpfs ускорения работы - обычно очень плохая идея.

А ты сделай объем tmpfs в 30% объема RAM и потом расскажи нам о результатах.

Обоснуйте. Пока ваше предложение похоже на предложение Брежнева из анекдота.

за вредоносный код в офрепе его вполне могут подвесить за яйца.

В _самом худшем_ случае для него это некоторый ущерб репутации (потому что понятно, что не он сам это сделал, а какой-то из мэйнтейнеров).

То есть мне для каждой проги из ppa надо лезть на сайт разработчиков чтобы сверить md5sum prog-x.y.z.orig.tar.gz с md5sum prog-x.y.z.tar.gz, опубликованным на сайте разработчика?

«Каждой»? У тебя их что, десятки? Но да, слазить на сайт - это меньше работы, чем сделать бэкпорт самому.

Ага, а еще если даже исходники хорошие и соответствуют авторским, то это еще не гарантирует того, что бинарь собран именно из них. В свой левый ppa я могу ведь залить любой треш :)

У меня вообще этого бага нет. Я просто держу в памяти многолетнюю историю этот проблемы и не спешу с выводами. Если у тебя этого нет это не значит что у других нет. В багзилле активность минимальная, понять ушла проблема или затаилась по ней нельзя.

А про суть проблемы я в курсе. Только дело не в полосе пропускания а в том что при попытке записи повисают все задачи во время сброса грязных страниц на диск.

У тебя их что, десятки?

Да

Но да, слазить на сайт - это меньше работы, чем сделать бэкпорт самому.

Работы на самом деле больше. Потому что я должен буду сделать аудит этих пакетов, потом убедить своих админов, что с _этим_ пакетом в _этой_ версии всё хорошо, потом убедить их прописать левые источники в sources.list. И после этого мне никто не гарантирует, что в следующей версии пакета из этого источника не окажется троян. В случае со своим бэкпортом работы гораздо меньше.

Не бинарники я тоже не люблю и не использую. Все из исходников ставлю двумя командами nixos-checkout && nixos-rebuild switch

У тебя их что, десятки?

Да

Афигеть. Тогда, похоже, ты что-то не так делаешь.

В случае со своим бэкпортом работы гораздо меньше.

Только каталог vendor/ становится гигабайтовым :)

Я бы тупо отключил tmpfs и увеличил swap. Возможно, еще бы уменьшил -j.

Ну про tmpfs несколько мнений - кто то говорит, что это хорошо, а кто то плохо. Думаю, что от сценария зависит.
У меня 8 ядер (четыре честных, 4 благодаря ht), посему и стоит -j9. Может и стоит еще раз попробовать отключить ht и сделать -j5.

P.S. использование tmpfs ускорения работы - обычно очень плохая идея.

Почему? Диск то меньше дергается.

Афигеть. Тогда, похоже, ты что-то не так делаешь.

У нас еще по божески. В соседнем проекте паранойя дошла до такой степени, что у них в 3rdparty лежит всё начиная от gcc и заканчивая иксовыми библиотеками :)

Только каталог vendor/ становится гигабайтовым :)

Винты сейчас резиновые, всё стерпят :)

удобная юнити помогает со всем этим работать достаточно быстро и без нервотрепки.

Уф.. как же достаёт это уже. Хорошие продукты в рекламе не особо нуждаются. А ты про свою Убунту как про дешёвые прокладки...

Кстати, а больше нигде не осталось 12309 на новых ядрах? Когда он впервые появился? Как долго просуществовал?

Ну про tmpfs несколько мнений - кто то говорит, что это хорошо, а кто то плохо.

Интересно было бы узнать доводы тех, кто говорит «это хорошо».

использование tmpfs ускорения работы - обычно очень плохая идея.

Почему?

Потому что оставляет VMM меньше места для маневра. Если ты распаковал на нее сорцы, ты тем самым уменьшил объем памяти, доступной для рабочей нагрузки (компиляции).

Диск то меньше дергается.

Иллюзия. Данные обычных ФС кэшируются почти так же эффективно, как и tmpfs, но при этом их можно сбросить на внешний носитель (или просто похерить).

в десяки, если не сотни раз ниже чем для Gentoo
я пробывал
но попробывать попробывал

Вначале я подумал, что это школьник Петя. Пораскинул мозгами и понял, это пестец.

Слышь ни трогай маего однокласника. Мы с ним нидавно поставили линекс и мы теперь крутые с нами даже десятиклассники за руку сдароваються

В соседнем проекте паранойя дошла до такой степени, что у них в 3rdparty лежит всё начиная от gcc и заканчивая иксовыми библиотеками :)

Если это именно паранойя (а не тяга к новым версиям), это другое дело.

Главное чтобы новое DKMS с oss к нему не забыли, а так да 3.2 с бекпортов много плюется неважными по сути сообщениями. Таки 32-е наше все

не скажи. Гентушникам tmpfs к примеру очень важен - для /var/tmp/portage например. Нахрена мне сбрасывать на винт временные объектные файлы, генерируемые при сборке пакетов?

@модераторы трите ветку начиная от вброса ато он работает.

Гентушникам tmpfs к примеру очень важен - для /var/tmp/portage например. Нахрена мне сбрасывать на винт временные объектные файлы

Чтобы не поддерживать миф 12309.

а как в сусе 12.1 заполучить это ядро? а то в оф. репх только 3.1.* и 3.3.*.

Иллюзия. Данные обычных ФС кэшируются почти так же эффективно, как и tmpfs, но при этом их можно сбросить на внешний носитель (или просто похерить).

Довод принят. Сча отключу tmpfs.

а и не надо там ничего интересного нет для тех кто не экспериментирует.

ЗЫ однако лэйзимерж для генты пока перспективнее хоть и не работает пока.

нет не всегда смотрит на федору, но в новом рхел не будет 3.2 по причине получения к тому времени ЛТС статуса для 3.4

если я правильно понял то в новой схеме каждое чётное по второй цифре ядро будет ЛТС

задолбали пиарить антипиар. пишите по делу и по теме.

Чтобы не поддерживать миф 12309.

Кстати да:

# du -sh /var/tmp/portage/
1.2G	/var/tmp/portage/

это вообще не баг это миф. причём скорее всего очень железоспецифичный и кроме как тюнингом поведения под оборудование не решится.

это вообще не баг это миф.

это не миф, это то с чем я столкнулся и с чем доолго боролся.

скорее всего очень железоспецифичный

да не скажи, много народу на этом погорело. Да и как это может быть с железом или дровами связано если проблема на уровне vfs? Не, ну может и есть зависимость (я так понимаю никто до сих пор не втыкает что это было), но очень не похоже на это.

мм?

Опять баттхёрт юзеров минорных дистрибутивов?

Кроме Debian 7.0 Wheezy ядро версии 3.2 используется в

А что, деб 7 уже вышел?

Нет, в тестинге находится.

... ядро версии 3.2 используется в вышедшей в конце апреля Ubuntu 12.04 LTS, для которой срок поддержки заявлен в пять лет.

в 3.3 у меня зато этот баг: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625922

Не нужно, есть linux-next.