В анонсе (http://lkml.iu.edu/hypermail/linux/kernel/1506.0/02415.html) нового выпуска ядра Linux 2.6.32.67 объявлено о скором завершении поддержки одной из старейших LTS-веток ядра, выпуск обновлений для которой производится с 2009 года. Ядро 2.6.32 достаточно активно используется командами дистрибутивов Linux, например, на базе этого ядра остроены Debian 6, RHEL 6, Ubuntu 10.04 LTS и SUSE 11SP1. Через несколько месяцев планируется прекратить выпуск обновлений для ядра 2.6.32, поэтому пользователям рекомендуется заранее спланировать переход на LTS-ядра 3.2 или 3.4.
В настоящее время LTS-обновления продолжают выходить для веток 3.2, 3.4, 3.10, 3.12, 3.13, 3.14, 3.16 и 3.19. Выпуски 3.19, 3.13 и 3.16 поддерживаются силами компании Canonical, обновления для них будут выпускаться до июня/апреля 2016 года (далее, поддержку ядра 3.16 подхватит проект Debian, который использует данное ядро в Debian 8 "Jessie"). Из longterm-веток (http://www.opennet.me/opennews/art.shtml?num=31475), поддерживаемых Грегом Кроа-Хартманом, можно отметить (https://kernel.org/) версии 3.14, 3.10 и 3.4. Обновления для ветки 3.14 будут выпускаться до августа 2016 года, для ветки 3.10 до сентября 2015 года, а для ветки 3.4 будет прекращено в ближайшее время. Поддержку ветки 3.2 взял в свои руки Ben Hutchings, входящий в команду мэйнтейнеров пакета с ядром Linux проекта Debian (ядро 3.2 используется в Debian Wheezy и в Ubuntu 12.04 LTS). Ветку 3.12, поддержка которой будет осуществляться до 2016 года, курирует Jiri Slaby из компании SUSE.URL: http://lkml.iu.edu/hypermail/linux/kernel/1506.0/02415.html
Новость: http://www.opennet.me/opennews/art.shtml?num=42369
Ура! На конец-то!
> Ура! На конец-то!Не вижу ничего радостного в этой новости как в принципе и ничего очень уж трагического тоже. Система как работала так и будет работать, тут всё так же как это было с M$ XP.
> Но только при наличии живых репозиториев, в противном случае это кака, которую
> сложно обновить без траблов до актуальной версии.Вообще-то обновление в первом приближении делается так: репы переключаются на новые и пакетный манагер просто накатывает новые версии пакетов, которые он ВНЕЗАПНО увидел.
Грабли конечно возможны везде. Вон там у людей ракеты падают и АЭС взрываются, а уж система на компьютере и подавно развалиться может. Но в целом все вполне культурно. А ваши любимые винды например так вообще не умеют.
> я сомневаюсь, что современные тарболы будут на нём собираться.
Фифти-фифти. Ну так, по опыту использования убунт 10.04 на сервере, последние из которых были проапгрейжены лишь недавно. Есть разработчики которые заморачиваются совместимостью, а есть те кто не любит копаться в архаике и воркэраундить старые баги. Де факто - чем старе система тем больше становится шанс что сборка не пройдет гладко. Но это постепенный процесс.
> Ценность старых ядер стремится к нулю.
Ядро - это такая подложка-запускалка для юзермода. И по факту большинство юзермода, кроме какого-то глубоко системного софта и прочая - не видит разницы между ядрами чуть менее чем никак и вообще плевать хотело на версию ядра. Исключение - системный софт которому надо какие-то свежие ультракульные нестандартные плюшки.
> На Linux ядра устаревают, по сути, после выхода следующей мажорной версии.
А вы кто вообще, чтобы рассказыать столь лживые байки?
> великий прогресс из-за какой-то стабильности.
Вы знаете, иногда улучшения в работе системы - таки очень велкам. Хотя можно и как мелкосакс - продавать 15 лет систему, в которой окошко консоли все такое же у...щное как и 15 лет назад.
А как же squeeze-lts с ядром 2.6.32 ?
> А как же squeeze-lts с ядром 2.6.32 ?Гм, есть такое.
2.6.32 Willy Tarreau 2009-12-03 Mid-2015
vs
Debian 6 “Squeeze” until February 2016На CKT вряд ли перекинут: "Ubuntu 10.04 [/Server/] will reach end of life on Thursday, April 30th"
Бен может взяться и понести "груз" до февраля. Но он только-только скинул [upstream~] 3.19, вздохнул, наверное.
http://metadata.ftp-master.debian.org/changelogs//main/l/lin...
...""not sure any of these are important enough to upload yet. At present
I'm intending to defer these until a more critical issue needs fixing
= https://lists.debian.org/debian-lts/2015/04/msg00052.html...
А могут и кинуть: как с броузерами "а необходимости в [безопасно-поддерживаемых] мозиллах у вас больше нет". Ядро не самое главное в системе -- все на systemd!!
Мне вдруг стало интересно, а как эволюционировала производительность ядра 2.6.32 в процессе, поднялась или упала? Есть гденить сравнения?
Делал когда-то, получается смотря с чем сравнивать и по каким критериям...В принципе Вы можете и сами проверить поставить OLDOLDStable (он же сквизи) от проекта DEBIAN GNU/Linux, выбрав для сравнения определённые критерии =)
Ну, тоесть, ощутимого улучшения или ухудшения не проявилось? Мне это и не нравится. Что с линуксом ни делай, он всё такой же. И реальных оптимизаций в длительной поддержке никто не делает, просто исправляют ошибки, которые "не портят и хорошо". Всё складывается так как сложилось и как ил оседает. Всё. Больше ничего не происходит. Годами. Десятилетиями. Как с ядром, так и со всем софтом. Эх...
Хочешь прироста скорости? Обновись с 2.6.32 до 3.16.7! А в 2.6.32.1000 нужны только исправления найденных ошибок, и ничто больше! Вот тебе пакеты для Debian 5.0 x86: https://yadi.sk/d/ykHfOVmjfvTyj Чтобы работал acpid, установи версию 10.0.10 из backports. Если нужно ядро для Debian 6.0 - говори, соберу.
Мне не надо. Я просто не заметил разницы (в лучшую сторону) при обновлениях, переходя от версии к версии. Даже похороникс отмечает, что от версии к версии ядро становится тяжелее, запись медленнее и т.д. Можно сделать скидку на то, что включенный код требует обкатки в боевых условиях, не оптимизирован пока. Но я думал, что, может, старые версии как-то оптимизируются, должны же быть перфекционисты, добивающиеся от своего проекта максимума, годами оттачивая, плоды таких трудов неизменно бы попали в патчи, но нет.
Хотите, чтобы годами оттачивали - поставьте РеактОс, только потом не жалуйтесь.
Понимаете, в чем фишка: код можно оптимизировать, не портя. То есть он останется читаемым, поддерживаемым и реализующим определенную абстракцию, внутрь которой можно без нужды не заглядывать.
А можно оптимизировать жестко. Экономя команды, подгоняя выполнение под юзкейсы, зажимая память до необходимых минимумов. Это будет работать быстрее и эффективнее, но поддерживать такой код станет на порядки сложнее.
Поэтому программисты не занимаются ерундой, а оптимизируют код только до той степени, которая достигается без искажения логики и за разумное время. Если при этом код отрабатывает достаточно быстро - больше никто с ним возиться и не будет. Если недостаточно - в первую очередь рассматривается возможность другого решения задачи. И только если ее нет - приходится оптимизировать ассемблерными вставками и прочими потенциально опасными вещами. Но не все же ядро!
> Хотите, чтобы годами оттачивали - поставьте РеактОс, только потом не жалуйтесьУже 15 лет оттачивают! Так все и оттачивают. Что ни...я не работает. Зато когда отточат... только я наверное до этого не доживу :)
http://www.phoronix.com/scan.php?page=article&item=linux-41-...
> Хочешь прироста скорости? Обновись с 2.6.32 до 3.16.7!Не факт, 2.6.32 было весьма шустрым.
По производительности как Windows XP SP1
По производительности чего?
GUI, которые разные? 3D, которые разные? Файловых систем, которые разные?Наверное, просто с той же скоростью вращает часики в курсоре...
> Наверное, просто с той же скоростью вращает часики в курсоре...Наверное, с той же скоростью вращает системные часики, во :)
>RHEL 6 - 30 ноября 2020
>Debian 6 - февраль 2016
>Ubuntu 10.04 Server - 30 апреля 2015
>SLES 11 SP1 - 30 августа 2015сразу видно, кто насколько беспокоится о своих пользователях
Зато ядро 4.1 будет LTSным. Hail T-800!
Код OpenVZ для 3.10 уже открыли.http://lists.openvz.org/pipermail/announce/2015-April/000579...
> Код OpenVZ для 3.10 уже открыли.Ога, не успело и 4.1 релизнуться. Знаете, за 2 года вкусная нямка умудряется превратиться в перегной.