ALT Linux Bugzilla – #5085

Наверное, всё-таки стоит прописывать разные поля Summary: для разных ядер? Тем
более, что текст есть про это: http://www.freesource.info/wiki/Altlinux/Kernels

Гош, давай придумаем конкретные англоязычные формулировки для текущих ядер.

(In reply to comment #2)
> Гош, давай придумаем конкретные англоязычные формулировки для текущих ядер.

Ну а http://www.freesource.info/wiki/Altlinux/Kernels-то чем не катит? Перевести
на аглицкий?

Ммм... угу, прямо summary|description и получаются, разве что в wks26 придётся
местами поменять (хотя на wiki и правильно читается).

Сделаешь, раз уж повесил? :)

(In reply to comment #4)
> Сделаешь, раз уж повесил? :)
Переводы сделать? Пожалуйста. 
http://www.freesource.info/wiki/Altlinux/Kernels/PackageDescription
А вот пакеты с ядрами пачтить... Это надо майнтейнеров пинать. Или ручки
отращивать новые, с автономными глазками :(
http://www.freesource.info/wiki/Altlinux/Kernels/PackageDescription

Ну давай предложим твои переводы lakostis@ для wks и ovz; спасибо.

Имхо, если кто не разбирается в названиях кернелов, ему нет смысла вникать
дальше std-smp :) 

Тогда так и нужно написать в описании std-smp, что оно рекомендуется к
установке. Но если в wks-smp будет хоть немного слов о том, чем оно отличается
от std-smp, будет очень неплохо. По себе знаю, наличие двух пакетов непонятно
чем отличающихся, очень раздражает.

Видимо теперь это моя бага. 

Угу, и если поймать, скажем, меня в офисе, мы составим планчик и я напишу тебе текстики. Это если ты сам не можешь справиться :)

(В ответ на комментарий №9)
> Видимо теперь это моя бага. 
Ага. Ping.

Кстати да, было бы неплохо в Summary указать чем отличаются ядра.

# apt-cache search "^kernel-image" | sed 's/[^ ]* - //' | wc     
     11      85     548
# apt-cache search "^kernel-image" | sed 's/[^ ]* - //' | sort -u | wc
      7      51     344
# apt-cache search "^kernel-image" | sed 's/[^ ]* - //' | sort -u
Intel optimized Clear Linux native kernel
Linux kvm kernel
The Linux kernel (I-pipe) 4.19.177-cip44-x86-17 with Xenomai 3.1 real-time Cobalt core
The Linux kernel (the core of the Linux operating system)
The Linux kernel with OpenVZ support
The Linux kernel with PREEMPT_RT patches (Real-Time Linux)
Uncompressed linux kernel for XEN domU boot
# uname -m
x86_64

Медленно, но верно!

По всей видимости, стоит поправить:
kernel-image-clr-kvm - Linux kvm kernel^W^W^WIntel optimized Clear Linux kvm kernel
и придумать разные имена для std-debug, std-def, un-def.

(Ответ для Arseny Maslennikov на комментарий #13)
> По всей видимости, стоит поправить:
> kernel-image-clr-kvm - Linux kvm kernel^W^W^WIntel optimized Clear Linux kvm
> kernel

  Done:

$ apt-cache search kernel-image-clr-kvm 
kernel-image-clr-kvm - Intel optimized Clear Linux kvm kernel

(In reply to Arseny Maslennikov from comment #13)
> Медленно, но верно!
> 
> По всей видимости, стоит
> придумать разные имена для std-debug, std-def, un-def.

На ум пришли варианты:

kernel-image-std-def - LTS Linux kernel
kernel-image-un-def - Rolling Linux kernel (-stable)
kernel-image-std-debug - LTS Linux kernel with debugging bits

Можно обсуждать/исправлять, но, ради всего святого, без слова unstable: оно неточное, часто неверное, даёт ложные коннотации (особенно если обмазать адмонициями и красными, как октябрь, ворнингами) и отпугивает коммьюнити. "Чур меня, чур от вашего Сизифа". Лучше говорить то же самое, но более мягкими словами.

В сторону: может, нам нужен kflavour, который по таймингам на полрелиза-релиз отстаёт от torvalds master branch, а сам представляет собой linux-stable +-? А un-def превратится в настоящее авангардное ядро, с пылу, с жару, с поддержкой свежайших устройств и недобитыми багами в iwlwifi.

(Ответ для Andrew Vasilyev на комментарий #14)
> (Ответ для Arseny Maslennikov на комментарий #13)
> > По всей видимости, стоит поправить:
> > kernel-image-clr-kvm - Linux kvm kernel^W^W^WIntel optimized Clear Linux kvm
> > kernel
> 
>   Done:
> 
> $ apt-cache search kernel-image-clr-kvm 
> kernel-image-clr-kvm - Intel optimized Clear Linux kvm kernel

Не надо переименовывать пакеты по аналогии с другими пакетами! clr-kvm не является "Intel optimized Clear Linux kvm kernel". Называйте, пожалусйта, пакеты по смыслу их содержания.

(In reply to Vitaly Chikunov from comment #16)
> Не надо переименовывать пакеты по аналогии с другими пакетами! clr-kvm не
> является "Intel optimized Clear Linux kvm kernel". Называйте, пожалусйта,
> пакеты по смыслу их содержания.

Каков же смысл содержания clr-kvm?

((kernel-image-clr-kvm-5.4.109-alt1-0-g78ee9b0df8a5))$ git diff --stat kernel-image-std-def-5.4.109-alt1|cat
 .gear/config     | 4637 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 .gear/linux.spec |  195 +++
 .gear/rules      |    4 +-
 3 files changed, 4835 insertions(+), 1 deletion(-)

Видимо, это старый std-def с измененным конфигом. Наверное, лучше было его назвать -std-kvm, например. Так как никаких Интел опимизацй из Клеарлинукса в нём нет, то не правильно называть его тем, чем оно не является.

(In reply to Vitaly Chikunov from comment #18)
> ((kernel-image-clr-kvm-5.4.109-alt1-0-g78ee9b0df8a5))$ git diff --stat
> kernel-image-std-def-5.4.109-alt1|cat
>  .gear/config     | 4637
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  .gear/linux.spec |  195 +++
>  .gear/rules      |    4 +-
>  3 files changed, 4835 insertions(+), 1 deletion(-)
> 
> Видимо, это старый std-def с измененным конфигом. Наверное, лучше было его
> назвать -std-kvm, например. Так как никаких Интел опимизацй из Клеарлинукса
> в нём нет, то не правильно называть его тем, чем оно не является.

Надо с этим разобраться в bug 39908 тогда.
А то префикс -clr там откуда-то взялся...

(Ответ для Arseny Maslennikov на комментарий #15)
> В сторону: может, нам нужен kflavour, который по таймингам на
> полрелиза-релиз отстаёт от torvalds master branch, а сам представляет собой
> linux-stable +-? А un-def превратится в настоящее авангардное ядро, с пылу,
> с жару, с поддержкой свежайших устройств и недобитыми багами в iwlwifi.

Не понятно почему в баге про переименование ядер для переименование одного ядра вдруг заводится отдельный баг, а новую тему предлагается обсуждать тут.

На сколько я понимаю, un-def это и есть последний linux-stable. А std-def последний longterm. +/-

Как torvalds master branch может быть linux-stable опять не понятно.

Зачем переименовывать un-def - не понятно. Если нужно авангардное ядро, то всегда есть ещё буквы, например avg-dev.
Кстати, у нас есть теперь футуристическое ядро drm-tip, оно на пол года новее чем torvalds master branch.

(In reply to Vitaly Chikunov from comment #20)
> (Ответ для Arseny Maslennikov на комментарий #15)
> > В сторону: может, нам нужен kflavour, который по таймингам на
> > полрелиза-релиз отстаёт от torvalds master branch, а сам представляет собой
> > linux-stable +-? А un-def превратится в настоящее авангардное ядро, с пылу,
> > с жару, с поддержкой свежайших устройств и недобитыми багами в iwlwifi.
> 
> Не понятно почему в баге про переименование ядер для переименование одного
> ядра вдруг заводится отдельный баг, а новую тему предлагается обсуждать тут.

Не предлагается — для того и подпись "в сторону". :)

> Насколько я понимаю, un-def это и есть последний linux-stable. А std-def
> последний longterm. +/-

ОК, это объяснение понятно.

> 
> Как torvalds master branch может быть linux-stable опять не понятно.

Да никак. "По таймингам" != "по содержанию". По содержанию они не могут совпадать, никто обратного не утверждает.

> 
> Зачем переименовывать un-def - не понятно.

Если вышеприведённых аргументов из comment 15 про тлетворное слово unstable недостаточно, тогда и не надо — я переживу как-нибудь, и, надеюсь, никто об это не споткнётся больше никогда.

А, я даже не думал, что "un" это "unstable".

> нужен kflavour, который по таймингам на полрелиза-релиз отстаёт от
> torvalds master branch, а сам представляет собой linux-stable +-? 

> Да никак. "По таймингам" != "по содержанию". По содержанию они не
> могут совпадать, никто обратного не утверждает.

Предлагается новый вид stable ядер? Или в чем предложение состоит - я просто не понял что имелось ввиду.

(In reply to Vitaly Chikunov from comment #22)
> А, я даже не думал, что "un" это "unstable".

Можно придумать другое толкование "un"; тогда проблема отпадёт.

Сейчас это в статусе городской легенды:
> Andrew Vasilyev, [10.04.21 23:32]
> Кстати, недавно на канале alt кто-то это расшифровал (std-def), AFAIR
> 
> Andrew Vasilyev, [10.04.21 23:33]
> "я подозреваю, что unstable default и standard default" antohami

Это andy@ говорит про телеграмный чат, где пользователи тусуются и задают каверзные вопросы, на которые даже разработчики альта ответ не знают:
> PS, [13.03.21 14:04]
> напомните пожалуйста ,в чём отличия ядер std-def и un-def (по их возможностям и > особенностям)
> 
> Антон Мидюков, [13.03.21 14:06]
> [In reply to PS]
> версия разная. un-def новее
> 
> NF, [13.03.21 14:13]
> [In reply to Антон Мидюков]
> Как un-def и std-def расшифровываются?
> 
> Антон Мидюков, [13.03.21 14:20]
> [In reply to NF]
> я подозреваю, что unstable default и standard default
Смешно называть linux-stable словом unstable, не правда ли?

(In reply to Vitaly Chikunov from comment #22)
> 
> > нужен kflavour, который по таймингам на полрелиза-релиз отстаёт от
> > torvalds master branch, а сам представляет собой linux-stable +-? 
> 
> > Да никак. "По таймингам" != "по содержанию". По содержанию они не
> > могут совпадать, никто обратного не утверждает.
> 
> Предлагается новый вид stable ядер? Или в чем предложение состоит - я просто
> не понял что имелось ввиду.

Да. Вкратце:
* std-def — LTS (как сейчас)
* новое ядро — rolling stable (то, что я имел в виду: его версия 5.X релизится в сизиф через 3-4 недели после релиза 5.X у Линуса; берётся актуальный linux-stable на эту дату. В остальном — как нынешний сизифный un-def). Я бы на нём и сидел, например;
* un-def — свежайшее с пылу с жару, чуть ли не torvalds branch (если вообще оно кому-то нужно).

Вот это будет вполне логичный нейминг.

Я бы предложил переключиться совсем на другую схему, для того, что бы иметь несколько LTS и stable ядер в одном репозитории

например так:
kernel-image-lts-5.4
kernel-image-lts-5.10
kernel-image-stable-5.11
т.е. - включать major версию ядра в имя пакета
Ну и придумать схему замены (или через update-kernel или хитрыми provides).

(Ответ для Arseny Maslennikov на комментарий #24)
> * новое ядро — rolling stable (то, что я имел в виду: его версия 5.X
> релизится в сизиф через 3-4 недели после релиза 5.X у Линуса; берётся
> актуальный linux-stable на эту дату. В остальном — как нынешний сизифный
> un-def).

В чем разница этой схемы с un-def?

(Ответ для Arseny Maslennikov на комментарий #15)
> (In reply to Arseny Maslennikov from comment #13)
> > Медленно, но верно!
> > 
> > По всей видимости, стоит
> > придумать разные имена для std-debug, std-def, un-def.
> 
> На ум пришли варианты:
> 
> kernel-image-std-def - LTS Linux kernel
> kernel-image-un-def - Rolling Linux kernel (-stable)
> kernel-image-std-debug - LTS Linux kernel with debugging bits
> 
> Можно обсуждать/исправлять, но, ради всего святого, без слова unstable: оно

Немного истории. un в слове un-def это не unstable. Это, к сожалению, вообще не имеющая за собой смысла часть. Когда мантейнером ядер был sillicium@, я начал собирать это ядро для личных целей в виде наиболее свежего релизного ядра от kernel.org. А название являлось шуткой, так как определённый flavour придумать было по правилам сложно, а undef это в Perl "отсутствие значения". А потом я стал мантейнером ядер, ядро un-def перестало быть таким уж неофициальным, стало попадать в дистрибутивы и в всё заверте...

(In reply to Anton V. Boyarshinov from comment #27)
> (Ответ для Arseny Maslennikov на комментарий #15)
> > (In reply to Arseny Maslennikov from comment #13)
> > > Медленно, но верно!
> > > 
> > > По всей видимости, стоит
> > > придумать разные имена для std-debug, std-def, un-def.
> > 
> > На ум пришли варианты:
> > 
> > kernel-image-std-def - LTS Linux kernel
> > kernel-image-un-def - Rolling Linux kernel (-stable)
> > kernel-image-std-debug - LTS Linux kernel with debugging bits
> > 
> > Можно обсуждать/исправлять, но, ради всего святого, без слова unstable: оно
> 
> Немного истории. un в слове un-def это не unstable. Это, к сожалению, вообще
> не имеющая за собой смысла часть. Когда мантейнером ядер был sillicium@, я
> начал собирать это ядро для личных целей в виде наиболее свежего релизного
> ядра от kernel.org. А название являлось шуткой, так как определённый flavour
> придумать было по правилам сложно, а undef это в Perl "отсутствие значения".

Да-а... Когда я впервые увидел слово kernel-image-un-def, мне пришло в голову undefined из JS, а про Perl я ничего не знал тогда (и сейчас не владею). Но, казалось бы, что там может быть undefined...

> А потом я стал мантейнером ядер, ядро un-def перестало быть таким уж
> неофициальным, стало попадать в дистрибутивы и всё заверте...

Наверное, rolling-def было бы понятнее...

(In reply to Anton Farygin from comment #25)
> Я бы предложил переключиться совсем на другую схему, для того, что бы иметь
> несколько LTS и stable ядер в одном репозитории
> 
> например так:
> kernel-image-lts-5.4
> kernel-image-lts-5.10
> kernel-image-stable-5.11

lts-, stable- — хорошие префиксы: сразу понятно.
Но не хватает суффиксов: -def, -kvm, -rt, -preempt-none, -xenomai...


> т.е. - включать major версию ядра в имя пакета
> Ну и придумать схему замены (или через update-kernel или хитрыми provides).

А что это даст такого, чего нет сейчас?

(Ответ для Arseny Maslennikov на комментарий #29)

> 
> А что это даст такого, чего нет сейчас?

Да то же самое, что предлагалось изначально - понятное именование для пакетов с возможностью сопровождения одновременно нескольких веток LTS и Stable ядер.

1. В %description un-def написано:

  There are some kernel variants in ALT systems:
  * std-def: standard longterm kernel without preemption;
  * std-pae: variant of std-def kernel for i686 with 64G memory support;
  * std-debug: variant of std-def kernel kernel with some DEBUG options enabled;
  * un-def: more modern then std-def and with voluntary (on ppc64le) and
    forced (on x86) preemption enabled.
  * sn-def: insecure kernel for SecretNet only

Думаю, что имеет смысл в описании (и возможно Summary) un-def написать, что это latest stable kernel, а у std-def, что это latest longterm kernel. Это, кажется, более важное отличие этих ядер чем наличие preemption.

(2. При этом, у std-def CONFIG_PREEMPT_VOLUNTARY=y, то есть не совсем "without preemption", что было бы при CONFIG_PREEMPT_NONE=y "для серверов").

Если я правильно понимаю стратегию этих ядер, то на странице https://www.altlinux.org/Kernels/Flavours возможно, стоит так же внести изменения

3. Про std-def предлагаю заменить "При сборке используются патчи из -stable ядер" на "последнее longterm ядро".

4. Про un-def предлагаю заменить "Экспериментальное ядро" на "последнее stable ядро" [оба для десктопов].

(Ответ для Vitaly Chikunov на комментарий #31)

> Думаю, что имеет смысл в описании (и возможно Summary) un-def написать, что
> это latest stable kernel, а у std-def, что это latest longterm kernel. Это,
> кажется, более важное отличие этих ядер чем наличие preemption.

Увы, это правило более-менее выполняется только в Сизифе. А в бранчах они, как правило,не latest. Хотя un-def почти всегда новее std-def, это да.
 
> Если я правильно понимаю стратегию этих ядер, то на странице
> https://www.altlinux.org/Kernels/Flavours возможно, стоит так же внести
> изменения
> 
> 3. Про std-def предлагаю заменить "При сборке используются патчи из -stable
> ядер" на "последнее longterm ядро".
> 
> 4. Про un-def предлагаю заменить "Экспериментальное ядро" на "последнее
> stable ядро" [оба для десктопов].

Не актуально. Sisyphus перешёл на другую схему именования ядер