Summary: | All kernel images have one name | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Fr. Br. George <george> |
Component: | kernel-image-std-def | Assignee: | Vitaly Chikunov <vt> |
Status: | NEW --- | QA Contact: | qa-sisyphus |
Severity: | enhancement | ||
Priority: | P2 | CC: | andy, arseny, cas, kernelbot, led, placeholder, vt |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux | ||
Bug Depends on: | |||
Bug Blocks: | 7371 |
Description
Fr. Br. George
2004-08-27 15:40:53 MSD
Наверное, всё-таки стоит прописывать разные поля 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 ядро" [оба для десктопов]. |