[Comm] Варианты ядер

[Comm] Варианты ядер

[Gulay Boris]

Я прошу прощения, что возвращаю всех у обсуждению сборо ядра. Я хочу
обощить ту информацию, которая есть по ядрам и потом обновить
соответствуюшую страницу на wiki.
Итак, по репозиториям:
p5:
  Первая часть имени сборки:
    hpc - Что-то для выпокопроизводительных вычислений. Пожалуйста,
поясните подробнее.
    ovz - Ядро с поддержкой OpenVZ. тут всё понятно.
    rt - Ядро real time. Чео оно отличается от обычного и где это может
пригодиться?
    sec - Ядро с поддержкой grsec?
    std - Обычное ядро, с которым мы сравнивает все остальные.
  Вторая часть имени сборки:
    std - Обычное вариант этой сборки.
    rhel - Ядро от Red Hat Enterprixe Linux. В чём его фишка, по сравнению
с обычным?.
    smp - Эмм, судя по названию, поддерживает работу на многопроцессорных
машнах. Не очень понятно, чем оно отличается от std, учитывая что все
современные ядра это поддерживают.
    up - Что это?
    def - То же, что и std?
5.1 (пишу только отличающиеся):
  Первая часть имени сборки:
    el - То же, что и rhel.
    un - Что это?
  Вторая часть имени сборки:
    up - Что это?

Re: [Comm] Варианты ядер

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Thu, Aug 26, 2010 at 05:33:26PM +0400, Gulay Boris wrote:
> Я прошу прощения, что возвращаю всех у обсуждению сборо ядра. Я хочу
> обощить ту информацию, которая есть по ядрам и потом обновить
> соответствуюшую страницу на wiki.
Сообщество не может знать ответов на эти вопросы.
Спрашивайте сборщиков, о чём я вам сказал, собственно, уже давно.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

> В последнем wks26, как написано ниже, зависание при выходе из иксов.
> В остальных (два непоследних wks26 и непоследний std226) почему-то
> исчезли виртуальные консоли.
вы сами не запутались? "непоследний один" и "непоследний другой"
- это сильное высказывание.
		-- lakostis in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Comm] Варианты ядер

[Anton Farygin]

26.08.2010 17:33, Gulay Boris пишет:
> Я прошу прощения, что возвращаю всех у обсуждению сборо ядра. Я хочу
> обощить ту информацию, которая есть по ядрам и потом обновить
> соответствуюшую страницу на wiki.
> Итак, по репозиториям:
> p5:
>    Первая часть имени сборки:
>      hpc - Что-то для выпокопроизводительных вычислений. Пожалуйста,
> поясните подробнее.
	Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно. Нужно 
там, где есть Lustre, InfiniBand и необходимость строить быстрые 
числодробилки.
	hpc-def ядро мёртвое, рекомендуется hpc-skif

>      ovz - Ядро с поддержкой OpenVZ. тут всё понятно.
>      rt - Ядро real time. Чео оно отличается от обычного и где это может
> пригодиться?
>      sec - Ядро с поддержкой grsec?
>      std - Обычное ядро, с которым мы сравнивает все остальные.
>    Вторая часть имени сборки:
>      std - Обычное вариант этой сборки.
>      rhel - Ядро от Red Hat Enterprixe Linux. В чём его фишка, по сравнению
> с обычным?.
>      smp - Эмм, судя по названию, поддерживает работу на многопроцессорных
> машнах. Не очень понятно, чем оно отличается от std, учитывая что все
> современные ядра это поддерживают.
>      up - Что это?
>      def - То же, что и std?
> 5.1 (пишу только отличающиеся):
>    Первая часть имени сборки:
>      el - То же, что и rhel.
>      un - Что это?
>    Вторая часть имени сборки:
>      up - Что это?
> _______________________________________________
> community mailing list
> community@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community

Re: [Comm] Варианты ядер

[melcomtec]

26 августа 2010 г. 16:33 пользователь Gulay Boris <boris@boressoft.ru> написал:
> Я прошу прощения, что возвращаю всех у обсуждению сборо ядра. Я хочу
> обощить ту информацию, которая есть по ядрам и потом обновить
> соответствуюшую страницу на wiki.

Чрезвычайно нужное дело! Удачи, чтоб у Вас получилось задуманное!

26 августа 2010 г. 16:36 пользователь Andrey Rahmatullin
<wrar@altlinux.org> написал:

> Спрашивайте сборщиков, о чём я вам сказал, собственно, уже давно.

Ну так пусть ответят в рассылках те, кто в курсе

> Сообщество не может знать ответов на эти вопросы.

Это не форум, а рассылки. Если не тут искать компетентных в этом
вопросе людей, то где. Это раз.

Второе. Человек занялся очень важным делом. Кто в силах, тот поможет.
Кстати, спросите Вы у сборщиков, раз вы настолько компетентны, и
напишите ответ сюда - здорово поможете.
-- 
С уважением, Денис [melcomtec].

Re: [Comm] Варианты ядер

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On Thu, Aug 26, 2010 at 05:01:15PM +0300, melcomtec wrote:
> > Сообщество не может знать ответов на эти вопросы.
> Это не форум, а рассылки. 
Это не рассылки, а рассылка.

> Если не тут искать компетентных в этом вопросе людей, то где. Это раз.
Большинство компетентых (не только в этом вопросе, а вообще) людей эту
рассылку не читает.

> Второе. Человек занялся очень важным делом. Кто в силах, тот поможет.
Да я ж разве против.

> Кстати, спросите Вы у сборщиков,
Заняться мне больше нечем.

> раз вы настолько компетентны
Разве для этого нужна большая компетенция?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<dottedmag> Так. fs.i опять упал. Можно продолжать спокойно работать :)
<raorn> dottedmag: это ты его убил
<dottedmag> Чёрт, поднялся :)
<dottedmag> Lost: это не вика, это хостинг.
<raorn> dottedmag: он от твоих правок в депрессию впадает
<dottedmag> Lost: митраен обещает в выходные перенести на другое место.
<wRAR> это такая феерическая вика
<wRAR> и такой феерический комп
<raorn> это такой феерическй митраен

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Comm] Варианты ядер

[melcomtec]

26 августа 2010 г. 17:10 пользователь Andrey Rahmatullin
<wrar@altlinux.org> написал:
> On Thu, Aug 26, 2010 at 05:01:15PM +0300, melcomtec wrote:

>> Если не тут искать компетентных в этом вопросе людей, то где. Это раз.
> Большинство компетентых (не только в этом вопросе, а вообще) людей эту
> рассылку не читает.

А какие читают? (Только не говорите devel, мой почтовый адрес не
подпадает под "фейс контроль" :-) Нет правда, где они "обитают"? Я уже
вижу "свою" статью на Вики: места обитания компетентных в ALTLinux и
не только людей :-) А вообще, занятное дело. На форуме "некоторые"
твердили, что компетентные люди форум не читают - они в рассылках.
Оказалось, что и в рассылки они читают далеко не все.

> Разве для этого нужна большая компетенция?

А то нет? Поди знать их, сборщиков: кто сборщик, кто нет, кого
спрашивать, в какой рассылке, кто чего собрал, для какой нужды и
какого пня дал то или иное название. Тут нужна не просто компетенция.
Тут надо нечто большее. Вы бы для такой сложной цели подошли идеально!
С Вашим опытом и тайными знаниями - эх! Но, Вы заняты :-)

-- 
С уважением, Денис [melcomtec].

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Thu, Aug 26, 2010 at 08:10:07PM +0600, Andrey Rahmatullin wrote:
> > Если не тут искать компетентных в этом вопросе людей, то где. Это раз.
> Большинство компетентых (не только в этом вопросе, а вообще)
> людей эту рассылку не читает.

Ошибка раз: нужно не большинство, а достаточность.

> > Кстати, спросите Вы у сборщиков,
> Заняться мне больше нечем.

Неужели остужать пыл настолько интересней?

> > раз вы настолько компетентны
> Разве для этого нужна большая компетенция?

Вот разве что.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Thu, Aug 26, 2010 at 05:52:52PM +0300, melcomtec wrote:
> А вообще, занятное дело. На форуме "некоторые" твердили,
> что компетентные люди форум не читают - они в рассылках.
> Оказалось, что и в рассылки они читают далеко не все.

Да, рассылок довольно много (и всё равно мы регулярно учиняем
не то и не там).

Тем не менее уже ответивший rider@ водится и в devel@,
и в community@, и на форуме порой.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Thu, Aug 26, 2010 at 05:52:52PM +0300, melcomtec wrote:
> А то нет? Поди знать их, сборщиков: кто сборщик, кто нет, кого
> спрашивать, в какой рассылке, кто чего собрал, для какой нужды и
> какого пня дал то или иное название. 
Сборщик - свойство пакета.

> Тут надо нечто большее. Вы бы для такой сложной цели подошли идеально!
> С Вашим опытом и тайными знаниями - эх! Но, Вы заняты :-)
А это опять к вопросу о том, что знать о недокументированности альта лучше
было бы заранее.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

ab [n=ab@pdpc/supporter/professional/ab] теперь известен как ab[out]
<lioka> h[elp] -> ab[out]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Thu, Aug 26, 2010 at 05:33:26PM +0400, Gulay Boris wrote:
>     rt - Ядро real time. Чео оно отличается от обычного и где
>     это может пригодиться?
>     sec - Ядро с поддержкой grsec?

Это лучше спросить непосредственно у silicium@altlinux.
Мне кажеся, эти ядра практически не используются и можно
их не документировать.  Но могу ошибаться.

>     std - Обычное вариант этой сборки.

Скорее "стандартное дерево исходников альтовского ядра".

>     rhel - Ядро от Red Hat Enterprixe Linux. В чём его фишка,
>     по сравнению с обычным?.

В наборе редхатовских патчей.  Сложно кратко описать,
но это _не_ ядро от RHEL, а ядро для ALT Linux, собранное
из кодовой базы ядра RHEL.

>     smp - Эмм, судя по названию, поддерживает работу на
>     многопроцессорных машнах. Не очень понятно, чем оно
>     отличается от std, учитывая что все современные ядра это
>     поддерживают.
>     up - Что это?

Это некогда антипод smp, uniprocessor kernel.  Оба обозначения,
вообще говоря, устарели и хорошо бы от них постепенно избавиться.

PS 2 wrar: надо же, в rt-up как раз внятный Summary:
The Linux kernel with xenomai(RT) patch

>     def - То же, что и std?

Нет, это "default".

> 5.1 (пишу только отличающиеся):
>   Первая часть имени сборки:
>     el - То же, что и rhel.
>     un - Что это?

Насколько понимаю, это было нечто вроде шутки в плане #undef...
но лучше уточнить у boyarsh@altlinux :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Thu, Aug 26, 2010 at 09:01:45PM +0600, Andrey Rahmatullin wrote:
> > А то нет? Поди знать их, сборщиков: кто сборщик, кто нет,
> > кого спрашивать, в какой рассылке, кто чего собрал, для какой
> > нужды и какого пня дал то или иное название. 
> Сборщик - свойство пакета.

rpm -qip пакет.rpm
rpm -qp --lastchange пакет.rpm

> > Тут надо нечто большее. Вы бы для такой сложной цели подошли идеально!
> > С Вашим опытом и тайными знаниями - эх! Но, Вы заняты :-)
> А это опять к вопросу о том, что знать о недокументированности
> альта лучше было бы заранее.

Ну я когда успеваю -- предупреждаю :-)
Это ещё не самое страшное в жизни.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[melcomtec]

2 Michael Shigorin

Вот это ответ! Не человек, а энциклопедия! Кстати, я тут понял, что
книгу писать не надо. Нужно просто переиздать Ваши знания в печатном
виде.
-- 
С уважением, Денис [melcomtec].

Re: [Comm] Варианты ядер

[Андрей Черепанов]

26 августа 2010 melcomtec написал:
> > Разве для этого нужна большая компетенция?
> 
> А то нет? Поди знать их, сборщиков: кто сборщик, кто нет, кого
> спрашивать, в какой рассылке, кто чего собрал, для какой нужды и
> какого пня дал то или иное название.
Проще было бы не разводить флейм, а пойти на sisyphis.ru и посомтреть описание 
пакетов и адреса мейнтенеров.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [Comm] Варианты ядер

[melcomtec]

26 августа 2010 г. 18:41 пользователь Андрей Черепанов
<cas@altlinux.ru> написал:

> Проще было бы не разводить флейм, а пойти на sisyphis.ru и посомтреть описание
> пакетов и адреса мейнтенеров.

---------------------------
Флейм (от англ. flame -- огонь, пламя) -- <<спор ради спора>>, обмен
сообщениями в местах многопользовательского сетевого общения
представляющий собой словесную войну, нередко уже не имеющую отношения
к первоначальной причине спора. Сообщения флейма могут содержать
личные оскорбления, и зачастую направлены на дальнейшее разжигание
ссоры.
---------------------------

Где Вы это видели? Имела место быть небольшая, гомеопатическая доза
здорового юмора. Но в итоге всё благополучно выяснилось, благодаря
Михаилу Шигорину и Антону Фарыгину (надеюсь я верно перевёл с
английского), за что им огромное спасибо.

-- 
С уважением, Денис [melcomtec].

Re: [Comm] Варианты ядер

[Gulay Boris]

On Thu, 26 Aug 2010 18:02:05 +0300, Michael Shigorin <mike@osdn.org.ua>
wrote:
Михаил, спасибо за подробный ответ. Письма разослал.

На текущий момент ситуация такая
p5:
  Первая часть имени сборки:
    hpc - Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно.
Нужно 
там, где есть Lustre, InfiniBand и необходимость строить быстрые 
числодробилки. Ядро мёртвое, рекомендуется hpc-skif.
    ovz - Ядро с поддержкой OpenVZ.
    rt - Ядро real time. Собрано с поддержкой xenomai
(http://www.xenomai.org).
    sec - Ядро с поддержкой grsec (http://www.grsecurity.net).
    std - Обычное ядро, с которым мы сравнивает все остальные.
  Вторая часть имени сборки:
    std - Обычное вариант этой сборки.
    rhel - Ядро, собранное с патчами от RHEL.
    smp - Пока так и не понятно, чем отличается от def и std.
    up - Что это?
    def - default. Что такое default?
5.1 (пишу только отличающиеся):
  Первая часть имени сборки:
    el - То же, что и rhel.
    un - Что это?
  Вторая часть имени сборки:
    up - Что это?

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Thu, Aug 26, 2010 at 05:33:26PM +0400, Gulay Boris wrote:

GB> Я прошу прощения, что возвращаю всех у обсуждению сборо ядра. Я хочу
GB> обощить ту информацию, которая есть по ядрам и потом обновить
GB> соответствуюшую страницу на wiki.

Хорошая идея.

Смотри в %changelog каждого ядра, там будет виден автор последнего
изменения. Его можно допросить о том, зачем он его собирает, и чем это
отличается от std-def.

Мнения людей, которые не упомянуты в %changelog могут быть ошибочными.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Thu, Aug 26, 2010 at 05:48:56PM +0400, Anton Farygin wrote:

AF> 	Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно. Нужно 
AF> там, где есть Lustre, InfiniBand и необходимость строить быстрые 
AF> числодробилки.
AF> 	hpc-def ядро мёртвое, рекомендуется hpc-skif

А чем оно отличается то std-def кроме люстры и модулей infiniband?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Thu, Aug 26, 2010 at 05:52:52PM +0300, melcomtec wrote:

m> А какие читают? (Только не говорите devel, мой почтовый адрес не
m> подпадает под "фейс контроль" :-) Нет правда, где они "обитают"? Я уже
m> вижу "свою" статью на Вики: места обитания компетентных в ALTLinux и
m> не только людей :-) А вообще, занятное дело. На форуме "некоторые"
m> твердили, что компетентные люди форум не читают - они в рассылках.
m> Оказалось, что и в рассылки они читают далеко не все.

Странно, но обычно читают собственную почту и собственный jabber.

Спрашивать в рассылке имеет смысл когда ты не знаешь точно кто тебе
ответит, или нужно множество ответов, или brainstorm над проблемой. Или
для того, чтобы ответ попал в архивы.

Если задающий вопрос собирается выкладывать результат компиляции собранных
данных на wiki -- то имеет все шансы получить обстоятельный ответ в
почте/jabber.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

On Thu, Aug 26, 2010 at 06:03:12PM +0300, Michael Shigorin wrote:

MS> rpm -qip пакет.rpm
MS> rpm -qp --lastchange пакет.rpm

О! За lastchange спасибо.

Еще у тех, кто сам является членом команды есть волшебный инструмент --
ssh git.alt acl --help

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

On Thu, Aug 26, 2010 at 06:02:05PM +0300, Michael Shigorin wrote:

>>     smp - Эмм, судя по названию, поддерживает работу на
>>     многопроцессорных машнах. Не очень понятно, чем оно
>>     отличается от std, учитывая что все современные ядра это
>>     поддерживают.
>>     up - Что это?
MS> Это некогда антипод smp, uniprocessor kernel.  Оба обозначения,
MS> вообще говоря, устарели и хорошо бы от них постепенно избавиться.

Поддержка SMP требует от ядра делать много дополнительных телодвижений.
За счет этого SMP-ядро на однопроцессорной машине слегка медленнее чем
обычное. Поэтому исторически сложилось, что в ALT собирались отдельно
smp-версии.

А потом в ядре появилась замечательная фича -- те куски кода, которые
разные для SMP и UP собираются оба, а при загрузке (не знаю точно) кажись
просто указатели на функции подменяются, в зависимости от того что нам
нужно.

Так что современные ядра на однопроцессорных системах не имеют
дополнительных тормозов, а на SMP позволяют насладиться высокой
производительностью :)

Так что на сегодняшний момент суффикс 'smp' это атавизм, который, думаю,
лучше вообще убрать из имен ядер чтобы не смущать людей типа "а что,
другие ядра без поддержки SMP?" в те времена, когда уже не-SMP систему
становится трудно найти в дикой природе :)


-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Thu, Aug 26, 2010 at 10:39:11PM +0400, Денис Смирнов wrote:
> Еще у тех, кто сам является членом команды есть волшебный
> инструмент -- ssh git.alt acl --help

http://git.altlinux.org/acl/
http://git.altlinux.org/acl/list.packages.sisyphus

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 3231 bytes --]

On Thu, Aug 26, 2010 at 08:00:33PM +0400, Gulay Boris wrote:
> On Thu, 26 Aug 2010 18:02:05 +0300, Michael Shigorin <mike@osdn.org.ua>
> wrote:
> Михаил, спасибо за подробный ответ. Письма разослал.
> 
> На текущий момент ситуация такая
> p5:
>   Первая часть имени сборки:
>     hpc - Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно.
> Нужно 
> там, где есть Lustre, InfiniBand и необходимость строить быстрые 
> числодробилки. Ядро мёртвое, рекомендуется hpc-skif.
>     ovz - Ядро с поддержкой OpenVZ.
>     rt - Ядро real time. Собрано с поддержкой xenomai
> (http://www.xenomai.org).
>     sec - Ядро с поддержкой grsec (http://www.grsecurity.net).
>     std - Обычное ядро, с которым мы сравнивает все остальные.
>   Вторая часть имени сборки:
>     std - Обычное вариант этой сборки.
>     rhel - Ядро, собранное с патчами от RHEL.
>     smp - Пока так и не понятно, чем отличается от def и std.

Сейчас в большинстве случаев уже ничем - в связи с распространением
многоядерных процессоров без SMP уже никуда.

>     up - Что это?

Это ядра без поддержки многопроцессорных и многоядерных конфигураций;
сейчас на x86 мало кому нужны, кроме специфических случаев (например,
сборка под конкретное железо с выжиманием последних процентов скорости
от убирания NOP, вставляемых SMP Alternatives при отключении поддержки
SMP).

>     def - default. Что такое default?

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

> 5.1 (пишу только отличающиеся):
>   Первая часть имени сборки:
>     el - То же, что и rhel.
>     un - Что это?
>   Вторая часть имени сборки:
>     up - Что это?

На самом деле структура этих имён не столь аккуратная, как хотелось
бы.  Изначально складывалось, что первая часть имени соответствует
применённым к коду ядра патчам, добавляющим те или иные функции, а
вторая - варианту конфигурации, при этом ядра с совпадающей первой
частью имени фактически собираются из одного и того же исходного кода.
В связи с этим, например, пакет kernel-doc-std собирался один для
вариантов ядер std-up и std-smp (тогда разделение было ещё таким - по
наличию поддержки многопроцессорных/многоядерных конфигураций).
Сейчас местами такая схема нарушилась (правда, там, где она нарушена,
тот же пакет kernel-doc-*, похоже, просто перестали собирать).

Для второй части имени сборки пропущен один важный вариант, который,
правда, существует только для 32-битной сборки (i586):

   pae - ядро с поддержкой Physical Address Extension (PAE),
	 позволяющее адресовать в 32-разрядном режиме более 4 ГБ
	 физической памяти (теоретически до 64 ГБ).  Этот вариант ядра
	 нужен для полного использования >= 4 ГБ ОЗУ в 32-разрядной
	 системе; для 32-разрядного ядра без PAE в этом случае будет
	 доступно от 2 до 3,5 ГБ ОЗУ в зависимости от настроек BIOS.
	 Собирать оба варианта приходится из-за того, что ядро с
	 поддержкой PAE не может запускаться на процессорах, не
	 поддерживающих PAE, а в эту категорию, помимо совсем уж
	 устаревших сейчас Pentium, попадают также первые версии
	 Pentium M.  Для x86_64 подобные ограничения старых
	 процессоров уже неактуальны, поэтому ядер *-pae там нет.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Владимир Гусев]

> [..]

А kernel-image-std-ng что значит?
Что такое ng?


-- 
С уважением,
Владимир Гусев

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

On Thu, Aug 26, 2010 at 09:45:39PM +0300, Michael Shigorin wrote:

MS> http://git.altlinux.org/acl/
MS> http://git.altlinux.org/acl/list.packages.sisyphus

Ой. Спасибо.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Шенцев Алексей Владимирович]

On Friday 27 August 2010 00:47:37 Владимир Гусев wrote:
> > [..]
>
> А kernel-image-std-ng что значит?
> Что такое ng?
new generation, если не совру
вариант ядра от shrek@
вот тут его ответ, на ваш вопрос:
http://lists.altlinux.org/pipermail/sisyphus/2010-April/346487.html
-- 
С уважением, Шенцев Алексей Владимирович.

Re: [Comm] Варианты ядер

[Dmitriy Kruglikov]

26 августа 2010 г. 16:33 пользователь Gulay Boris написал:
>    un - Что это?
Ядро, содержащее все, что нужно и не требующее модулей.

>  Вторая часть имени сборки:
>    up - Что это?
В отличие от smp-ядер, однопроцессорные ...



-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [Comm] Варианты ядер

[Gulay Boris]

Спасибо всем ответишим. Актуальный вариант списка ядер - ниже. Я решил
отказаться от разделения по бранчам т.к. описание уже, в целом, готово.
Окинте, пожалуйста, мою работу критическим взглядом и выскажите замечания,
если они появяться.

Первая часть имени сборки:
  hpc - Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно.
Нужно там, где есть Lustre, InfiniBand и необходимость строить быстрые 
числодробилки.
  ovz - Ядро с поддержкой OpenVZ.
  rt - Ядро real time. Собрано с поддержкой xenomai
(http://www.xenomai.org).
  sec - Ядро с поддержкой grsec (http://www.grsecurity.net).
  std - Обычное ядро, с которым мы сравнивает все остальные.
  el - То же, что и rhel (см. ниже).
  un - Ядро, содержащее все, что нужно и не требующее модулей.
  tmc - Ядро для терминалов.

Вторая часть имени сборки:
  std - Обычный вариант этой сборки.
  def - Обычный вариант этой сборки.
  smp - Обычный вариант этой сборки (используется как антипод up для ядер,
имеющих обе версии).
  rhel - Ядро, собранное с патчами от RHEL
(http://ru.wikipedia.org/wiki/Red_Hat_Enterprise_Linux).
  up - Ядро без поддержки многопроцессорных и многоядерных конфигураций.
Сейчас на x86 нужно редко, например, сборка под конкретное железо с 
выжиманием последних процентов скорости от убирания NOP, вставляемых 
SMP Alternatives при отключении поддержки SMP.
  pae - Ядра с поддержкой Physical Address Extension (PAE, 
http://ru.wikipedia.org/wiki/PAE), позволяющей  адресовать в 32-разрядном 
режиме более 4 ГБ физической памяти (теоретически до 64 ГБ).  Этот 
вариант ядра нужен для полного  использования >= 4 ГБ ОЗУ в 32-разрядной 
системе. для 32-разрядного ядра без PAE в этом случае будет доступно 
от 2 до 3,5 ГБ ОЗУ в зависимости от настроек BIOS. Собирать оба варианта 
приходится из-за того, что ядро с поддержкой PAE не может запускаться на 
процессорах, не поддерживающих PAE, а в эту категорию, помимо совсем уж 
устаревших сейчас Pentium, попадают также первые версии Pentium M.  Для 
x86_64 подобные ограничения старых процессоров уже неактуальны, поэтому 
ядер *-pae там нет.
  skif - Ядро (только hpc) для суперкомпьютера СКИФ
(http://skif.pereslavl.ru/skif).
  tc - Ядро (только tmc) для терминалов.

Re: [Comm] Варианты ядер

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

On Fri, Aug 27, 2010 at 11:24:49AM +0400, Gulay Boris wrote:
>   std - Обычное ядро, с которым мы сравнивает все остальные.
Опечатка: "сравниваем"

>   un - Ядро, содержащее все, что нужно и не требующее модулей.
Вот из-за таких советов и советчиков я и предупреждал, что будет ерунда.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<dottedmag> wart: ты же читал этот пи**ец в office от тараса?
<dottedmag> "у нас очень большая вероятность что человек, пришедший работать,
            например, курьером или секретарём, через пару месяцев начнет
            чего-нибудь патчить или собирать пакеты..."
<thresh> :D
<dottedmag> Особый Путь, кля.
<dottedmag> ALT Way.
<dottedmag> Тупик Коммунизма.
<lodin_> . о О (идёт, стало быть, курьер, несет свежесобранный пакет)
<ilyak> А мы потом этими пакетами пользуемся

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

On Fri, Aug 27, 2010 at 09:41:39AM +0300, Dmitriy Kruglikov wrote:

DK> Ядро, содержащее все, что нужно и не требующее модулей.

Т.е. сферический конь в вакууме?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Dmitriy Kruglikov]

27 августа 2010 г. 11:44 пользователь Денис Смирнов написал:
> On Fri, Aug 27, 2010 at 09:41:39AM +0300, Dmitriy Kruglikov wrote:
>
> DK> Ядро, содержащее все, что нужно и не требующее модулей.
>
> Т.е. сферический конь в вакууме?
Нет.
Вполне себе среднестатистический конь с оптимальным набором...
Дополнительные модули не запрещены, но основной набор включен.
На моем ноуте поднялось практически все...

-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [Comm] Варианты ядер

[Gulay Boris]

On Fri, 27 Aug 2010 11:58:31 +0300, Dmitriy Kruglikov
<dmitriy.kruglikov@gmail.com> wrote:
> 27 августа 2010 г. 11:44 пользователь Денис Смирнов написал:
>> On Fri, Aug 27, 2010 at 09:41:39AM +0300, Dmitriy Kruglikov wrote:
>>
>> DK> Ядро, содержащее все, что нужно и не требующее модулей.
>>
>> Т.е. сферический конь в вакууме?
> Нет.
> Вполне себе среднестатистический конь с оптимальным набором...
> Дополнительные модули не запрещены, но основной набор включен.
> На моем ноуте поднялось практически все...
Критиков в рассылке достаточно. Причём, судя по их письмам, они-то знают,
что это за ядро на самом деле. Но просто-так нам это не расскажут.
Я написал письмо Антону Бояршинову. Судя по changelog
(http://sisyphus.ru/ru/srpm/Sisyphus/kernel-image-un-def/changelog) он
является автором последнего изменения в обсуждаемом ядре.

Re: [Comm] Варианты ядер

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

On Fri, Aug 27, 2010 at 01:05:54PM +0400, Gulay Boris wrote:
> Критиков в рассылке достаточно. Причём, судя по их письмам, они-то знают,
> что это за ядро на самом деле. Но просто-так нам это не расскажут.
Ерунду пишете.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

> хочу перейти на 2.6 (в дистре ATLM24 ведь он есть).
не надо переползать на 2.6, которое идет в ALM2.4. Даже не думайте об
этом.
		-- lakostis in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Comm] Варианты ядер

[Gulay Boris]

On Fri, 27 Aug 2010 15:08:00 +0600, Andrey Rahmatullin <wrar@altlinux.org>
wrote:
> On Fri, Aug 27, 2010 at 01:05:54PM +0400, Gulay Boris wrote:
>> Критиков в рассылке достаточно. Причём, судя по их письмам, они-то
>> знают,
>> что это за ядро на самом деле. Но просто-так нам это не расскажут.
> Ерунду пишете.
Спасибо за аргументированное возражение.

Re: [Comm] Варианты ядер

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Fri, Aug 27, 2010 at 01:12:59PM +0400, Gulay Boris wrote:
> >> Критиков в рассылке достаточно. Причём, судя по их письмам, они-то
> >> знают, что это за ядро на самом деле. Но просто-так нам это не
> >> расскажут.
> > Ерунду пишете.
> Спасибо за аргументированное возражение.
У меня нет и не может быть аргументов против подобных необоснованных
высказываний.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

Это не довод, чтобы рушить систему.
		-- ldv in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Fri, Aug 27, 2010 at 11:24:49AM +0400, Gulay Boris wrote:
> Спасибо всем ответишим. Актуальный вариант списка ядер - ниже.

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

Лучше по каждому отдельно, см. ниже.

> Я решил отказаться от разделения по бранчам

Угу.

> Первая часть имени сборки:

Фактически указание на майнтейнера и его задачу.
("ядра у нас авторские [и не коллективные]")

>   hpc - Ядро для суперкомпьютеров. Обычным людям, как правило,
> не нужно.  Нужно там, где есть Lustre, InfiniBand и
> необходимость строить быстрые числодробилки.
>   ovz - Ядро с поддержкой OpenVZ.
>   rt - Ядро real time. Собрано с поддержкой xenomai
> (http://www.xenomai.org).
>   sec - Ядро с поддержкой grsec (http://www.grsecurity.net).
>   std - Обычное ядро, с которым мы сравнивает все остальные.

IMHO лучше "Ядро по умолчанию".

>   el - То же, что и rhel (см. ниже).

Лучше el описать, а rhel сделать ссылкой (или вообще убрать).

>   un - Ядро, содержащее все, что нужно и не требующее модулей.

Это не так, существует две дюжины пакетов kernel-modules-*un-def*.

>   tmc - Ядро для терминалов.

Лучше даже "Ядро для бездисковых тонких клиентов ALTSP".

> Вторая часть имени сборки:

Это лучше раздерибанить или превратить в список ключевых слов
с их значениями -- на "вторую часть" сейчас не тянет.

Например, el-smp должно бы тогда называться el-pae на i586
и el-smp на x86_64.

Так что лучше сделать табличку с общими фичами
("SMP/UP", "PAE", ...) и выставлять "SMP" или там "+"
соответственно.

>   up - [...]
>   pae - [...]

Лучше в <ref>...</ref> (и <references/> вниз).

>   skif - Ядро (только hpc) для суперкомпьютера СКИФ
> (http://skif.pereslavl.ru/skif).
>   tc - Ядро (только tmc) для терминалов.

Как видим, эти теги в обобщения тоже не годятся.


On Fri, Aug 27, 2010 at 01:40:27PM +0600, Andrey Rahmatullin wrote:
> >   un - Ядро, содержащее все, что нужно и не требующее модулей.
> Вот из-за таких советов и советчиков я и предупреждал,
> что будет ерунда.

Читаю я
http://lists.altlinux.org/pipermail/devel/2003-November/016422.html
http://lists.altlinux.org/pipermail/sisyphus/2003-December/251321.html
http://lists.altlinux.org/pipermail/devel-kernel/2003-December/002930.html
http://lists.altlinux.org/pipermail/sisyphus/2003-December/252085.html
-- и вспоминаю те времена, когда и цитирование было попроще,
и вопросы поглупей, и советы с прорехами порой...
хорошие были времена.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[Comm] [JT] о суждениях в рассылке

[Michael Shigorin]

On Fri, Aug 27, 2010 at 03:19:43PM +0600, Andrey Rahmatullin wrote:
> On Fri, Aug 27, 2010 at 01:12:59PM +0400, Gulay Boris wrote:
> > >> Критиков в рассылке достаточно. Причём, судя по их
> > >> письмам, они-то знают, что это за ядро на самом деле.
> > >> Но просто-так нам это не расскажут.

Это было не столько "необоснованное высказывание",
сколько "опрометчивое суждение".

> > > Ерунду пишете.
> > Спасибо за аргументированное возражение.
> У меня нет и не может быть аргументов против подобных
> необоснованных высказываний.

Интересно, если б тебя или меня в первый год так вот шпыняли,
много бы толку через три года получилось?  Как бздишник прям.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Михаил]

Здравствуйте, Gulay.

Вы писали 27 августа 2010 г., 13:05:54:

> Критиков в рассылке достаточно. Причём, судя по их письмам, они-то знают,
> что это за ядро на самом деле. Но просто-так нам это не расскажут.

Точно,   мы  такие.  Создали  заговор  среди  тех  кто  все  знает,  и
договорились никому ничего не рассказывать. ;)

А  если  серьезно,  перестаньте  глупости  говорить.   Причина намного
банальней.   Огромное  количество  флейма,  флуда, личной переписки, и
прочего  информационного  мусора в рассылках, требует много времени на
прочтение.

А   хорошие   специалисты,  таким  богатством,  как  лишнее  время  не
располагают.  И тратить его на чтение информационного мусора обычно не
желают.   Практически   по   этому  и не читают все рассылки, и многие
темы в них.

По  этому и действительно нужные темы то же остаются не прочитанными и
без   ответными.  Поставить  сюда  модератора  из  старых  фидошников,
установить  такие же жесткие правила, и мусора станет в разы меньше, и
тогда  реально  появится  шанс, что все компетентные люди будут больше
прочитывать,  и как следствии больше отвечать. Правда бОльшая половина
пИсателей в течении недели уйдет в R/O и бан.

-- 
С уважением,
 Михаил                          mailto:consc@mail.ru

Re: [Comm] Варианты ядер

[Gulay Boris]

On Fri, 27 Aug 2010 16:51:11 +0400, Михаил <consc@mail.ru> wrote:
> Здравствуйте, Gulay.
> 
> Вы писали 27 августа 2010 г., 13:05:54:
> 
>> Критиков в рассылке достаточно. Причём, судя по их письмам, они-то
>> знают,
>> что это за ядро на самом деле. Но просто-так нам это не расскажут.
> 
> Точно,   мы  такие.  Создали  заговор  среди  тех  кто  все  знает,  и
> договорились никому ничего не рассказывать. ;)
> 
> А  если  серьезно,  перестаньте  глупости  говорить.   Причина намного
> банальней.   Огромное  количество  флейма,  флуда, личной переписки, и
> прочего  информационного  мусора в рассылках, требует много времени на
> прочтение.
Правильно ли я понимаю, что те, кто критиковал моё описание, на самом деле
не владеют необходимым обёмом информации о предмете? Тогда почему они
считают возможным сказать, то описание неверно, если они не знают, какое
описание будет верным?
Если же знают, почему они просто констатируют факт неточности описания но
не указывают правильный вариант?
Объясните.

Re: [Comm] Варианты ядер

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

On Fri, Aug 27, 2010 at 05:49:20PM +0400, Gulay Boris wrote:
> Правильно ли я понимаю, что те, кто критиковал моё описание, на самом деле
> не владеют необходимым обёмом информации о предмете? 
Да, конечно.

> Тогда почему они считают возможным сказать, то описание неверно,
Потому что видят, что оно неверно.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<at_> и ещё вопрос, у меня firefox много жрёт памяти и падает
<at_> есть какой-нибудь плагин чтобы он не жрал памяти и не падал или нет

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Comm] Варианты ядер

[Gulay Boris]

On Fri, 27 Aug 2010 19:59:07 +0600, Andrey Rahmatullin <wrar@altlinux.org>
wrote:
> On Fri, Aug 27, 2010 at 05:49:20PM +0400, Gulay Boris wrote:
>> Правильно ли я понимаю, что те, кто критиковал моё описание, на самом
>> деле
>> не владеют необходимым обёмом информации о предмете?
> Да, конечно.
> 
>> Тогда почему они считают возможным сказать, то описание неверно,
> Потому что видят, что оно неверно.
Как можно констатировать неверность некоторого утверждения, если ты не
знаешь его верную интерпритация?

Re: [Comm] Варианты ядер

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Fri, Aug 27, 2010 at 06:02:21PM +0400, Gulay Boris wrote:
> >> Правильно ли я понимаю, что те, кто критиковал моё описание, на самом
> >> деле
> >> не владеют необходимым обёмом информации о предмете?
> > Да, конечно.
> > 
> >> Тогда почему они считают возможным сказать, то описание неверно,
> > Потому что видят, что оно неверно.
> Как можно констатировать неверность некоторого утверждения, если ты не
> знаешь его верную интерпритация?
Ммда.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

Что касается войны дистрибутивов, то с моей точки зрения как члена одной
из команд, все эти юзерско-ламерские дискуссии весьма забавны и показывают
лишь насколько их участники не в состоянии понять положение дел в
сообществе разработчиков. Даже несмотря на то, что им его разъясняют.
		-- aen in talk-room@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

On Fri, Aug 27, 2010 at 06:02:21PM +0400, Gulay Boris wrote:

GB> Как можно констатировать неверность некоторого утверждения, если ты не
GB> знаешь его верную интерпритация?

Даже не зная точно кто ты, можно констатировать неверность утверждения что
ты марсианин.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Gulay Boris]

On Fri, 27 Aug 2010 18:41:59 +0400, Денис Смирнов <mithraen@altlinux.ru>
wrote:
> On Fri, Aug 27, 2010 at 06:02:21PM +0400, Gulay Boris wrote:
> 
> GB> Как можно констатировать неверность некоторого утверждения, если ты
не
> GB> знаешь его верную интерпритация?
> 
> Даже не зная точно кто ты, можно констатировать неверность утверждения
что
> ты марсианин.
Ты обладаешь исчерпывающей информацией о Марсе, я правильно понимаю?

Re: [Comm] Варианты ядер

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On Fri, Aug 27, 2010 at 06:49:39PM +0400, Gulay Boris wrote:
> > GB> Как можно констатировать неверность некоторого утверждения, если ты
> не
> > GB> знаешь его верную интерпритация?
> > 
> > Даже не зная точно кто ты, можно констатировать неверность утверждения
> что
> > ты марсианин.
> Ты обладаешь исчерпывающей информацией о Марсе, я правильно понимаю?
Кончайте словоблудить.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<AlexSid> hiddenman: iptables: Too many links - что может быть?
<thresh_> удали пакеты elinks и links

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Comm] Варианты ядер

[melcomtec]

2 Gulay Boris

Вы, пожалуйста, не бросайте заниматься тем, что начали. Критику и
словоблудия можете воспринимать к сведению, но не слишком близко к
сердцу. Вы важное дело делаете и очень полезное. Поймите меня
правильно, я не собираюсь Вас учить - упаси Бог! Я просто не хочу,
чтобы Ваша энергия и то рвение, с которым Вы взялись за дело
растерялось на сопротивление тем, кто много чего говорит, но по сути
вопроса очень мало.

Успеха Вам и удачи!

-- 
С уважением, Денис [melcomtec].

Re: [Comm] Варианты ядер

[Михаил]

Здравствуйте, Gulay.

Вы писали 27 августа 2010 г., 17:49:20:

>>> Критиков  в  рассылке  достаточно.   Причём,  судя  по их письмам,
>>> они-то  знают,  что  это за ядро на самом деле.  Но просто-так нам
>>> это не расскажут.

>> Точно,   мы  такие.  Создали  заговор  среди  тех  кто  все  знает,  и
>> договорились никому ничего не рассказывать. ;)

>> А  если  серьезно,  перестаньте  глупости  говорить.   Причина намного
>> банальней.   Огромное  количество  флейма,  флуда, личной переписки, и
>> прочего  информационного  мусора в рассылках, требует много времени на
>> прочтение.

> Правильно ли я понимаю, что те, кто критиковал моё описание, на самом деле
> не владеют необходимым обёмом информации о предмете?

Если  честно,  таких  писем  не видел. Наверно фильтр прибивает у меня
письма  этих  критиков автоматически. И на основании этого, думаю, что
вы совершенно правы.

(Может  автора назовете, или ссылку на письмо в веб архиве дадите, что
бы говорить предметно?)

> Тогда  почему  они  считают  возможным сказать, то описание неверно,
> если они не знают, какое описание будет верным?

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

> Если же знают, почему они просто констатируют факт неточности описания но
> не указывают правильный вариант?

Да не знают они. Знали бы рассказали.

> Объясните.

Обычные рисовки ламеров, и не более. Вот и все объяснение.

-- 
С уважением,
 Михаил                          mailto:consc@mail.ru

[Comm] не: Варианты ядер

[Michael Shigorin]

On Fri, Aug 27, 2010 at 06:02:21PM +0400, Gulay Boris wrote:
> >> Правильно ли я понимаю, что те, кто критиковал моё описание,
> >> на самом деле не владеют необходимым обёмом информации о
> >> предмете?
> > Да, конечно.
> >> Тогда почему они считают возможным сказать, то описание
> >> неверно,
> > Потому что видят, что оно неверно.
> Как можно констатировать неверность некоторого утверждения,
> если ты не знаешь его верную интерпритация?

С обсуждением (не)культурных традиций и их последствий
предлагаю перебраться в smoke-room@, дабы не усугублять.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[Comm] Administriva

[Michael Shigorin]

On Fri, Aug 27, 2010 at 08:24:24PM +0400, Михаил wrote:
> Обычные рисовки ламеров

Так, где там мой плюсомёт, кто там по нему соскучился?

То вроде взрослые мужики, то опять из любого доброго порыва
болото сделают.  Стыдно за нас.  Прекратите.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Владимир Гусев]

>> > [..]
>> А kernel-image-std-ng что значит?
>> Что такое ng?
> new generation, если не совру
> вариант ядра от shrek@
> вот тут его ответ, на ваш вопрос:
> http://lists.altlinux.org/pipermail/sisyphus/2010-April/346487.html

Кроме совета там ничего нет.. просто неясно - в чем суть этого new  
generation? Чем это ядро отличается от других?


-- 
С уважением,
Владимир Гусев

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Fri, Aug 27, 2010 at 10:06:25PM +0400, Владимир Гусев wrote:
> >>А kernel-image-std-ng что значит?
> Чем это ядро отличается от других?

Выкинуто заведомо устаревшее, плюс бывал более новый drm,
чем в std-def (для экспериментов/использования нового xorg).
К бранчам это менее касательно, чем к сизифу.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Владимир Гусев]

On Fri, 27 Aug 2010 22:27:40 +0400, Michael Shigorin wrote:

>> >>А kernel-image-std-ng что значит?
>> Чем это ядро отличается от других?
>
> Выкинуто заведомо устаревшее, плюс бывал более новый drm,
> чем в std-def (для экспериментов/использования нового xorg).
> К бранчам это менее касательно, чем к сизифу.

А к бранчам и так давно уже почти ничего не касательно.. Все застопорилось  
на не самом лучшем 2.6.30. Вот и обратился к сизифу за ядрами - но и там  
фактически нечего брать, то модулей не последней значимости не хватает, то  
обязательная поддержка pae в ядре, где в названии нет -pae, да и никак не  
видно bfq и прочих интересных манипуляции свопа с памятью, про какие  
писали в анонсах к ядрам выше 2.6.32 (вроде 35 на дворе тестируют, если не  
36)..


-- 
С уважением,
Владимир Гусев

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Fri, Aug 27, 2010 at 11:48:33PM +0400, Владимир Гусев wrote:
> А к бранчам и так давно уже почти ничего не касательно..
> Все застопорилось  на не самом лучшем 2.6.30.

Это не совсем так.

> Вот и обратился к сизифу за ядрами

Рискуешь вляпаться по части KMS с xorg (там включено).

> (вроде 35 на дворе тестируют, если не  36)..

Недавно пролетало kernel-source-2.6.35-1.0.0-alt1.src.rpm,
я вот думаю, к чему бы это.  Но мне и не жмёт. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

On Fri, Aug 27, 2010 at 11:16:56PM +0300, Michael Shigorin wrote:

MS> Недавно пролетало kernel-source-2.6.35-1.0.0-alt1.src.rpm,
MS> я вот думаю, к чему бы это.  Но мне и не жмёт. :)

К TRIM в ext4? И к более стабильному btrfs, например? :)

P.S. У меня ~/ на xfs. Сегодня был в шоке, когда осознал насколько быстрее
на множестве мелких файлов работает ext4 (которая у меня на разделе с не
шибко ценными данными, для эксперимента).

Вот думаю как сравнить по конкурентному доступу к большим файлам, и,
возможно, просто избавиться от xfs.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[melcomtec]

28 августа 2010 г. 3:23 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:

> P.S. У меня ~/ на xfs. Сегодня был в шоке, когда осознал насколько быстрее
> на множестве мелких файлов работает ext4 (которая у меня на разделе с не
> шибко ценными данными, для эксперимента).

XFS надёжней ext4? В чём, если не секрет? Я знаю, что XFS очень
чувствительна к отключениям электроэнергии и потому необходимо
использовать UPS. Что скажете? Ваш опыт очень интересен, так как я
когда-то очень серьёзно выбирал себе файловую систему для работы в
экстремальных условиях с данными среднего уровня важности (не
безопасности, а важности, то есть потеря их в результате чего-либо
чревата сложностями, но секрета в них нет) и выбрал ext4fs с полным
журналированием. Я поступил не верно? Заранее благодарю за ответ.

-- 
С уважением, Денис [melcomtec].

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

On Sat, Aug 28, 2010 at 02:33:03PM +0300, melcomtec wrote:

m> XFS надёжней ext4? В чём, если не секрет? 

ext4 -- экспериментальная. XFS надежная и проверенная времени при условии
наличия UPS.

m> Я знаю, что XFS очень
m> чувствительна к отключениям электроэнергии и потому необходимо
m> использовать UPS. Что скажете? Ваш опыт очень интересен, так как я
m> когда-то очень серьёзно выбирал себе файловую систему для работы в
m> экстремальных условиях с данными среднего уровня важности (не
m> безопасности, а важности, то есть потеря их в результате чего-либо
m> чревата сложностями, но секрета в них нет) и выбрал ext4fs с полным
m> журналированием. Я поступил не верно? Заранее благодарю за ответ.

У меня под столом стоит рэковый UPS на 3kW, который мой комп часами может
держать. Мне все пофиг. Только он онлайновый и старенький уже -- надо бы
аккумуляторы заменить :)

Верно или нет ext4 -- неизвестно. FS сама по себе очень хорошая, просто
моя параноя не позволяет класть более-менее ценные данные на что-то
непроверенное.

У меня в планах на ближайее время перенести ~/ на SSD. И там будет ext4.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[Михаил]

Здравствуйте, Денис.

Вы писали 28 августа 2010 г., 16:49:03:

> У меня в планах на ближайее время перенести ~/ на SSD. И там будет ext4.

Во, что-то, а прежде чем ставить на SSD ext4, я бы очень и очень долго
думал.


-- 
С уважением,
 Михаил                          mailto:consc@mail.ru

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Sat, Aug 28, 2010 at 06:17:22PM +0400, Михаил wrote:
> > У меня в планах на ближайее время перенести ~/ на SSD.
> > И там будет ext4.
> Во, что-то, а прежде чем ставить на SSD ext4, я бы очень и
> очень долго думал.

Надо же, а я почитал, подумал и поставил.  Жалоб до сих пор нет.

$ df -Th -t ext4 
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/sda2     ext4    9.9G  5.4G  4.2G  57% /
/dev/sda4     ext4     96G   48G   43G  53% /home

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Sat, Aug 28, 2010 at 06:17:22PM +0400, Михаил wrote:

М> Во, что-то, а прежде чем ставить на SSD ext4, я бы очень и очень долго
М> думал.

Есть причины кроме распространенного заблуждения "журналируемые FS для SSD
это ужас-ужас"?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Comm] Варианты ядер

[REAL]

Gulay Boris пишет:
>   Первая часть имени сборки:
>     hpc - Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно.
> Нужно 
> там, где есть Lustre, InfiniBand и необходимость строить быстрые 
> числодробилки. Ядро мёртвое, рекомендуется hpc-skif.

Lustre и Infiniband необязательно. Главное, что машины объединены в 
кластер (это может быть и банальный Ethernet).

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Tue, Aug 31, 2010 at 02:11:51PM +0800, REAL wrote:
> >  Первая часть имени сборки:
> >    hpc - Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно.
> >Нужно 
> >там, где есть Lustre, InfiniBand и необходимость строить быстрые 
> >числодробилки. Ядро мёртвое, рекомендуется hpc-skif.
> Lustre и Infiniband необязательно. Главное, что машины
> объединены в кластер (это может быть и банальный Ethernet).

Предложенная формулировка верна -- _в том ядре_ есть то, что
нужно там, где _нужны_ люстра и IB.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Gulay Boris]

Пришёл ответ от Антона Бояршинова который пролил свет на ядро un. Кроме
этого я внёс исправления в соответствии с, высказанными в рассылке,
замечаниями.
Я готов выложить это на wiki.

Первая часть имени сборки (указывает на задачу, которую решал автор,
собирая это ядро):
  hpc - Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно.
Нужно там, где есть Lustre, InfiniBand и необходимость строить быстрые 
числодробилки.
  ovz - Ядро с поддержкой OpenVZ.
  rt - Ядро real time. Собрано с поддержкой xenomai
(http://www.xenomai.org).
  sec - Ядро с поддержкой grsec (http://www.grsecurity.net).
  std - Ядро по умолчанию с которым мы сравнивает все остальные.
  el - Ядро, собранное с патчами от RHEL
(http://ru.wikipedia.org/wiki/Red_Hat_Enterprise_Linux).
  un - Экспериментальное ядро для десктопов (было первым 2.6.32 ядром в
Сизифе). Включено kernel preemption
(http://en.wikipedia.org/wiki/Kernel_preemption), 
наложены патчи на drm из std-ng. Некоторые наработки и патчи из un-def
позже 
мигрируют в std-def.
  tmc - Ядро для бездисковых тонких клиентов ALTSP
(http://www.altlinux.org/LTSP).

Вторая часть имени сборки (указывает на особенности конкретной сборки
ядра):
  std - Обычный вариант этой сборки.
  def - Обычный вариант этой сборки.
  smp - Обычный вариант этой сборки (используется как антипод up для ядер,
имеющих обе версии).
  rhel - то же, что и el (см. выше).
  up - Ядро без поддержки многопроцессорных и многоядерных конфигураций.
Сейчас на x86 нужно редко, например, сборка под конкретное железо с 
выжиманием последних процентов скорости от убирания NOP, вставляемых 
SMP Alternatives при отключении поддержки SMP.
  pae - Ядра с поддержкой Physical Address Extension (PAE, 
http://ru.wikipedia.org/wiki/PAE), позволяющей  адресовать в 32-разрядном 
режиме более 4 ГБ физической памяти (теоретически до 64 ГБ).  Этот 
вариант ядра нужен для полного  использования >= 4 ГБ ОЗУ в 32-разрядной 
системе. для 32-разрядного ядра без PAE в этом случае будет доступно 
от 2 до 3,5 ГБ ОЗУ в зависимости от настроек BIOS. Собирать оба варианта 
приходится из-за того, что ядро с поддержкой PAE не может запускаться на 
процессорах, не поддерживающих PAE, а в эту категорию, помимо совсем уж 
устаревших сейчас Pentium, попадают также первые версии Pentium M.  Для 
x86_64 подобные ограничения старых процессоров уже неактуальны, поэтому 
ядер *-pae там нет.
  skif - Ядро (только hpc) для суперкомпьютера СКИФ
(http://skif.pereslavl.ru/skif).
  tc - только tmc (см. выше).

Re: [Comm] Варианты ядер

[REAL]

Michael Shigorin пишет:
>>>    hpc - Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно.
>>> Нужно 
>>> там, где есть Lustre, InfiniBand и необходимость строить быстрые 
>>> числодробилки. Ядро мёртвое, рекомендуется hpc-skif.
>> Lustre и Infiniband необязательно. Главное, что машины
>> объединены в кластер (это может быть и банальный Ethernet).
> 
> Предложенная формулировка верна -- _в том ядре_ есть то, что
> нужно там, где _нужны_ люстра и IB.

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

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Варианты ядер

[REAL]

Gulay Boris пишет:
>   hpc - Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно.
> Нужно там, где есть Lustre, InfiniBand и необходимость строить быстрые 
> числодробилки.

Только фриковые формулировки лучше убрать (я про "числодробилки"). 
По-человечески это звучит примерно как "высокопроизводительные 
вычисления" или, по вузовской дисциплине, "параллельные вычисления". 
Можно упомянуть и наличие возможности анализа производительности, 
которая присутствует только в ядрах hpc.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Варианты ядер

[REAL]

Michael Shigorin пишет:
>> Вообще, в формулировке нет даже расшифровки hpc, что может
>> заставить потенциальных пользователей думать, что это ядро
>> нужно _только_ там, где есть люстра и IB.
> 
> Интересно, чего тебе в std-def не хватает на гигабите?

1. HZ=100
2. Отсутствие Performance Monitoring Counters, из-за чего не работает 
perfctr


-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Варианты ядер

[Michael Shigorin]

On Wed, Sep 01, 2010 at 10:24:12AM +0800, REAL wrote:
> >Предложенная формулировка верна -- _в том ядре_ есть то, что
> >нужно там, где _нужны_ люстра и IB.
> Но эта формулировка неполноценна, о чём я и говорю.

1) у меня создалось впечатление "эта формулировка неверна";
2) внесёт человек на вики хоть обновлённый вариант,
   детали уже там можно дошлифовать :)

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

Интересно, чего тебе в std-def не хватает на гигабите?
(лучше лично)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[REAL]

Михаил пишет:
>> Вообще, в формулировке нет даже расшифровки hpc, что может заставить
>> потенциальных пользователей думать, что это ядро нужно _только_ там,
>> где есть люстра и IB.
> 
> Я то же в начале подумал, что это ядро для ноутов от Hewlett Packard и
> Compaq :)
> 
> Оказалось High Performance Cluster (высоко производительный кластер).

Нет, это High Performance Computing :)


-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [Comm] Варианты ядер

[Михаил]

Здравствуйте, REAL.

Вы писали 1 сентября 2010 г., 6:24:12:

> Michael Shigorin пишет:
>>>>    hpc - Ядро для суперкомпьютеров. Обычным людям, как правило, не нужно.
>>>> Нужно 

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

Я то же в начале подумал, что это ядро для ноутов от Hewlett Packard и
Compaq :)

Оказалось High Performance Cluster (высоко производительный кластер).

-- 
С уважением,
 Михаил                          mailto:consc@mail.ru

Re: [Comm] Варианты ядер

[Michael Shigorin]

(oops, забыл в postponed)

On Fri, Aug 27, 2010 at 12:32:18AM +0400, Sergey Vlasov wrote:
> >     smp - Пока так и не понятно, чем отличается от def и std.
> Сейчас в большинстве случаев уже ничем - в связи с
> распространением многоядерных процессоров без SMP уже никуда.

Всё ещё забавнее -- в el-smp включено и PAE.

[skip]

Спасибо, добавил к http://www.altlinux.org/Kernels

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Варианты ядер

[Gulay Boris]

По многочисленным просьбам поправил описание ядра hpc. В описание сборки
pae добавил ссылку на ALTLinux.wiki.

Первая часть имени сборки (указывает на задачу, которую решал автор,
собирая это ядро):
  hpc - Ядро для суперкомпьютеров (High Performance Computing). Обычным 
людям, как правило, не нужно, нужно там, где есть Lustre, InfiniBand и 
требуется наличие Performance Monitoring Counters.
  ovz - Ядро с поддержкой OpenVZ.
  rt - Ядро real time. Собрано с поддержкой xenomai
(http://www.xenomai.org).
  sec - Ядро с поддержкой grsec (http://www.grsecurity.net).
  std - Ядро по умолчанию с которым мы сравнивает все остальные.
  el - Ядро, собранное с патчами от RHEL
(http://ru.wikipedia.org/wiki/Red_Hat_Enterprise_Linux).
  un - Экспериментальное ядро для десктопов (было первым 2.6.32 ядром в
Сизифе). Включено kernel preemption
(http://en.wikipedia.org/wiki/Kernel_preemption), 
наложены патчи на drm из std-ng. Некоторые наработки и патчи из un-def
позже мигрируют в std-def.
  tmc - Ядро для бездисковых тонких клиентов ALTSP
(http://www.altlinux.org/LTSP).

Вторая часть имени сборки (указывает на особенности конкретной сборки
ядра):
  std - Обычный вариант этой сборки.
  def - Обычный вариант этой сборки.
  smp - Обычный вариант этой сборки (используется как антипод up для ядер,
имеющих обе версии).
  rhel - то же, что и el (см. выше).
  up - Ядро без поддержки многопроцессорных и многоядерных конфигураций.
Сейчас на x86 нужно редко, например, сборка под конкретное железо с 
выжиманием последних процентов скорости от убирания NOP, вставляемых 
SMP Alternatives при отключении поддержки SMP.
  pae - Ядра с поддержкой Physical Address Extension (PAE, 
http://ru.wikipedia.org/wiki/PAE), позволяющей  адресовать в 32-разрядном 
режиме более 4 ГБ физической памяти (теоретически до 64 ГБ).  Этот 
вариант ядра нужен для полного  использования >= 4 ГБ ОЗУ в 32-разрядной 
системе. для 32-разрядного ядра без PAE в этом случае будет доступно 
от 2 до 3,5 ГБ ОЗУ в зависимости от настроек BIOS (подробнее - 
http://www.altlinux.org/Kernels/PAE). Собирать оба варианта 
приходится из-за того, что ядро с поддержкой PAE не может запускаться на 
процессорах, не поддерживающих PAE, а в эту категорию, помимо совсем уж 
устаревших сейчас Pentium, попадают также первые версии Pentium M.  Для 
x86_64 подобные ограничения старых процессоров уже неактуальны, поэтому 
ядер *-pae там нет.
  skif - Ядро (только hpc) для суперкомпьютера СКИФ
(http://skif.pereslavl.ru/skif).
  tc - только tmc (см. выше).