[devel] HIMEM up

[devel] HIMEM up

[Andy Gorev]

Существует-ли какая-либо обоснованная причина отсутствия поддержки HIMEM 
в std-up ядре? Если не существует, или это решаемо, то добавте 
пожалуйста CONFIG_HIGHMEM4G=y
Ставить SMP не предлагать ;-)

ps подобная просьба звучит периодически и в комьюнити и в сизифе

-- 
С Уважением,
Андрей Горев

[devel] Re: HIMEM up

[Michael Shigorin]

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

On Wed, Aug 13, 2003 at 04:42:42PM +0300, Andy Gorev wrote:
> Существует-ли какая-либо обоснованная причина отсутствия
> поддержки HIMEM в std-up ядре? Если не существует, или это
> решаемо, то добавте пожалуйста CONFIG_HIGHMEM4G=y
> Ставить SMP не предлагать ;-)
> ps подобная просьба звучит периодически и в комьюнити и в сизифе

Что характерно, там же звучит обоснование, почему _сейчас_ так
уже не делается и почему предлагают ставить SMP или собирать
свое.

У меня другой вопрос -- нет ли у уважаемых kernel flavour
maintainers видения того, какие ядра нужны?

Пока предлагаю свои соображения:

- std: default.  То, что должно быть при отсутствии других
  соображений, штатным, поддерживаемым etc.  То, что "в общем
  случае" должно просто работать.

- aw: server default.  Думаю, объяснять, что фокус сборки и
  поддержки серверного ядра достаточно сильно отличается от
  "общих" и тем более "столовых" соображений.

- "mm"/"ws": нечто более мультимедийно-столовое, которое может
  позволить себе включать не очень проверенные драйверы нового
  железа, патчи вроде win4lin, lowlat, supermount или пяток
  версий NVIDIA, но зато работать на всем, что горит и быть более
  приемлемым решением вопроса, чем "соберите сами", по тем
  флангам, где "тенденция, однако" (как w4l или sm).

Так как политика развития aw определяется сугубо практическими
соображениями, то за него я спокоен в наибольшей мере.

Соображений по части (не)вхождения/заголосовывания/выкидывания
патчей в std я пока не припомню, но это скорее именно что
ответственность майнтейнера с данными QA и support@ на руках.

"mm" мне напоминает Костины ядра в части "работает на всем, но
иногда и на хорошем может странно себя вести" -- есть случаи,
когда лучше так, чем никак.

_Возможно_, "ws" -- несколько более другая ветка, нежели mm -- в
той части, что акцент смещен все же не в фичи, а в стабильность,
но при этом есть вещи, которые могут быть просто не нужны на
"обычном" или "мультимедийном" столе -- вроде того же highmem или
поддержки стримеров.

PS: есть и развитие темы по другому направлению -- сборки в
зависимости от архитектуры, которые учитывают бессмысленность
включения поддержки PS/2 или i440BX в athlon, KT400 -- в PIII или
ISA -- в P4 (?).  Но это явно не в этом году :)

PPS: мне показалось, что оригинальное письмо было в d-k@.
Перебираемся туда?

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

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

Re: [devel] Re: HIMEM up

[Anton Farygin]

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

Michael Shigorin пишет:
> On Wed, Aug 13, 2003 at 04:42:42PM +0300, Andy Gorev wrote:
> 
>>Существует-ли какая-либо обоснованная причина отсутствия
>>поддержки HIMEM в std-up ядре? Если не существует, или это
>>решаемо, то добавте пожалуйста CONFIG_HIGHMEM4G=y
>>Ставить SMP не предлагать ;-)
>>ps подобная просьба звучит периодически и в комьюнити и в сизифе
> 
> 
> Что характерно, там же звучит обоснование, почему _сейчас_ так
> уже не делается и почему предлагают ставить SMP или собирать
> свое.
> 
> У меня другой вопрос -- нет ли у уважаемых kernel flavour
> maintainers видения того, какие ядра нужны?
> 
> Пока предлагаю свои соображения:
> 
> - std: default.  То, что должно быть при отсутствии других
>   соображений, штатным, поддерживаемым etc.  То, что "в общем
>   случае" должно просто работать.
> 
> - aw: server default.  Думаю, объяснять, что фокус сборки и
>   поддержки серверного ядра достаточно сильно отличается от
>   "общих" и тем более "столовых" соображений.
> 
> - "mm"/"ws": нечто более мультимедийно-столовое, которое может
>   позволить себе включать не очень проверенные драйверы нового
>   железа, патчи вроде win4lin, lowlat, supermount или пяток
>   версий NVIDIA, но зато работать на всем, что горит и быть более
>   приемлемым решением вопроса, чем "соберите сами", по тем
>   флангам, где "тенденция, однако" (как w4l или sm).

supermount я поддерживать отказываюсь в каком ли бо виде.

Это не мультимедийно-столовое, а полное багов. Т.е. - для самоубийц.

> 
> Так как политика развития aw определяется сугубо практическими
> соображениями, то за него я спокоен в наибольшей мере.
> 
> Соображений по части (не)вхождения/заголосовывания/выкидывания
> патчей в std я пока не припомню, но это скорее именно что
> ответственность майнтейнера с данными QA и support@ на руках.
> 
> "mm" мне напоминает Костины ядра в части "работает на всем, но
> иногда и на хорошем может странно себя вести" -- есть случаи,
> когда лучше так, чем никак.
> 
> _Возможно_, "ws" -- несколько более другая ветка, нежели mm -- в
> той части, что акцент смещен все же не в фичи, а в стабильность,
> но при этом есть вещи, которые могут быть просто не нужны на
> "обычном" или "мультимедийном" столе -- вроде того же highmem или
> поддержки стримеров.
> 
> PS: есть и развитие темы по другому направлению -- сборки в
> зависимости от архитектуры, которые учитывают бессмысленность
> включения поддержки PS/2 или i440BX в athlon, KT400 -- в PIII или
> ISA -- в P4 (?).  Но это явно не в этом году :)
> 
> PPS: мне показалось, что оригинальное письмо было в d-k@.
> Перебираемся туда?

Ага... мы сделали технологию размножения ядер... только не надо 
говорить: "Плодитесь", а сначала попробуйте собрать из incoming хотя-бы 
то, что залил туда Альберт (ну и естественно sisyphus_check на это).

Дима предлагает сделать это Пете после нескольких неудачных попыток, а 
Петя загружен работой над std-up и std-smp ядрами.

В общем - лично я против, пока по крайней мере не допилим CVS и не 
сделаем _автоматизированную_ сборку kernel-* пакетов.

Rgds,
Rider

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

Re: [devel] Re: HIMEM up

[Kachalov Anton]

Anton Farygin пишет:

> Michael Shigorin пишет:
>
>> On Wed, Aug 13, 2003 at 04:42:42PM +0300, Andy Gorev wrote:
>>
>
> supermount я поддерживать отказываюсь в каком ли бо виде.
>
> Это не мультимедийно-столовое, а полное багов. Т.е. - для самоубийц.

да что верно, то верно -- кусок, который встравивается в ядро и вешается 
на многие девайсы (cdrom, block)
и самое главное - смысл этого supermount'a?

>
> Ага... мы сделали технологию размножения ядер... только не надо 
> говорить: "Плодитесь", а сначала попробуйте собрать из incoming 
> хотя-бы то, что залил туда Альберт (ну и естественно sisyphus_check на 
> это).
>
> Дима предлагает сделать это Пете после нескольких неудачных попыток, а 
> Петя загружен работой над std-up и std-smp ядрами.
>
> В общем - лично я против, пока по крайней мере не допилим CVS и не 
> сделаем _автоматизированную_ сборку kernel-* пакетов.

Согласен, размножение ядер лучше делать автоматизированным...

>
Rgds,
Anton

-- 
ALTLinux Team [http://www.altlinux.ru]
LRN Team [http://www.lrn.ru]
FreeCraft Team [http://freecraft.sourceforge.net]

Re: [devel] Re: HIMEM up

[Albert R. Valiev]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 830 bytes --]

В сообщении от 13 Август 2003 19:46 Anton Farygin написал:

> Ага... мы сделали технологию размножения ядер... только не
> надо говорить: "Плодитесь", а сначала попробуйте собрать из
> incoming хотя-бы то, что залил туда Альберт (ну и естественно
> sisyphus_check на это).

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

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

-- 

With Best Regards, Albert R. Valiev
------------------------------------
ALT Linux Team [www.altlinux.ru]
ARV-DARKSTAR-RIPN, ARV2-RIPE

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

Re: [devel] Re: HIMEM up

[Anton Farygin]

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

Albert R. Valiev пишет:
> В сообщении от 13 Август 2003 19:46 Anton Farygin написал:
> 
> 
>>Ага... мы сделали технологию размножения ядер... только не
>>надо говорить: "Плодитесь", а сначала попробуйте собрать из
>>incoming хотя-бы то, что залил туда Альберт (ну и естественно
>>sisyphus_check на это).
> 
> 
> Согласен, предпоследние ветви были неудачны для сборки те же 
> hasher-ом, однако не надо говорить про последние - после того 
> как все же заставил hasher работать я все собираю с ним. 

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

Далее - по отзывам LDV, на многие уже собранные пакеты не проходит 
sisyphus_check.

Я не к тому, что у тебя совсем все плохо - бывают ошибки у всех. Просто 
нам нужно поменять схему, по которой пакеты с ядрами попадают в 
sisyphus. Так сказать автоматизировать.

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

Альберт, я внимательно смотрел как работает supermount-ng:

В KDE: Вставь CD, открой его на чтение к konqueror, запусти с него 
что-то проигрывать (например музыку). Не закрывая ни одного окна вытащи 
CD, попробуй поработать с оставшимися окнами.

Rgds,
Rider

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

Re: [devel] Re: HIMEM up

[Albert R. Valiev]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1693 bytes --]

В сообщении от 14 Август 2003 09:02 Anton Farygin написал:
> Albert R. Valiev пишет:
> Далее - по отзывам LDV, на многие уже собранные пакеты не
> проходит sisyphus_check.

У меня на собранные hasher-ом пакеты sisyphus_check говорит 
только одно - you have a problem with package signatures

> Альберт, я внимательно смотрел как работает supermount-ng:

> В KDE: Вставь CD, открой его на чтение к konqueror, запусти с
> него что-то проигрывать (например музыку). Не закрывая ни
> одного окна вытащи CD, попробуй поработать с оставшимися
> окнами.

А что должно было произойти? У меня ничего странного не 
произошло. Мои действия - вставил диск с записанным видео 
файлом, открыл с konqueror, щелкнул по файлу - открылся xine, 
начал играть - вынул диск - xine остановился и все, никаких 
проблем больше не увидел. Далее для теста вставил диск с 
mp3-шками, также запустил - kaboodle проиграл часть файла, потом 
остановился после извлечения диска, но никаких проблем с окнами 
я не увидел вообще. спокойно переключался между ними, в конквере 
ходил по каталогам, спокойно закрыл как и xine, так и kaboodle - 
причем они не подвисли, просто остановились.

возможные проблемы могут быть связаны с написанием строки в 
fstab, у меня записи такие:

none /mnt/cdrom supermount 
fs=iso9660,dev=/dev/cdroms/cdrom1,--,codepage=866,iocharset=koi8-r,owner,user,umask=0  
0 0
none /mnt/dvdrom supermount 
fs=iso9660,dev=/dev/cdroms/cdrom0,--,codepage=866,iocharset=koi8-r,owner,user,umask=0  
0 0

да, у меня devfs. в alt4 оно включено, но без автомонтирования.


-- 

With Best Regards, Albert R. Valiev
------------------------------------
ALT Linux Team [www.altlinux.ru]
ARV-DARKSTAR-RIPN, ARV2-RIPE

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

Re: [devel] Re: HIMEM up

[Anton Farygin]

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

Albert R. Valiev пишет:
> В сообщении от 14 Август 2003 09:02 Anton Farygin написал:
> 
>>Albert R. Valiev пишет:
>>Далее - по отзывам LDV, на многие уже собранные пакеты не
>>проходит sisyphus_check.
> 
> 
> У меня на собранные hasher-ом пакеты sisyphus_check говорит 
> только одно - you have a problem with package signatures

Тогда все вопросы к ldv. Но схему для kernel-image нужно все равно менять.

Кстати - попробуй забрать с CVS скрипты для сборки ядер. Я писал раньше 
о них - они реально работают.

Хочу услышать твое мнение об этом ;-)

> 
> 
>>Альберт, я внимательно смотрел как работает supermount-ng:
> 
> 
>>В KDE: Вставь CD, открой его на чтение к konqueror, запусти с
>>него что-то проигрывать (например музыку). Не закрывая ни
>>одного окна вытащи CD, попробуй поработать с оставшимися
>>окнами.
> 
> 
> А что должно было произойти? У меня ничего странного не 
> произошло. Мои действия - вставил диск с записанным видео 
> файлом, открыл с konqueror, щелкнул по файлу - открылся xine, 
> начал играть - вынул диск - xine остановился и все, никаких 
> проблем больше не увидел. Далее для теста вставил диск с 
> mp3-шками, также запустил - kaboodle проиграл часть файла, потом 
> остановился после извлечения диска, но никаких проблем с окнами 
> я не увидел вообще. спокойно переключался между ними, в конквере 
> ходил по каталогам, спокойно закрыл как и xine, так и kaboodle - 
> причем они не подвисли, просто остановились.
> 
> возможные проблемы могут быть связаны с написанием строки в 
> fstab, у меня записи такие:
> 
> none /mnt/cdrom supermount 
> fs=iso9660,dev=/dev/cdroms/cdrom1,--,codepage=866,iocharset=koi8-r,owner,user,umask=0  
> 0 0
> none /mnt/dvdrom supermount 
> fs=iso9660,dev=/dev/cdroms/cdrom0,--,codepage=866,iocharset=koi8-r,owner,user,umask=0  
> 0 0
> 
> да, у меня devfs. в alt4 оно включен

Проблема, которую я наблюдал - два сильно зависших приложения (konqueror 
и xmms)

Rgds,
Rider

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

Re: [devel] Re: HIMEM up

[Ed V. Bartosh]

 AF> Это было два дня назад. Дело не в том, что что у тебя
 AF> плохие пакеты. Дело в том, что для сборки одних пакетов
 AF> требуются другие, а т.к. hasher не умеет сортировать
 AF> порядок сборки (не его это работа), то возникает достаточно
 AF> много проблем.

 AF> Далее - по отзывам LDV, на многие уже собранные пакеты не
 AF> проходит sisyphus_check.

 AF> Я не к тому, что у тебя совсем все плохо - бывают ошибки у
 AF> всех. Просто нам нужно поменять схему, по которой пакеты с
 AF> ядрами попадают в sisyphus. Так сказать автоматизировать.

Предлагалась же действующая схема, насколько я понимаю. И не только
для ядер, а более общая. Более того, предлагалось устранить в ней те 
недочеты, на которые было указано:
http://www.altlinux.ru/pipermail/devel/2003-August/014094.html

Предложение было оставлено без ответа. Почему, можно узнать ?

Результат все тот же - продолжаем изобретать велосипед с другой формой
колес в надежде на более удобную езду. Но мы уже едем, ребята ! Ауу !
Проснитесь, наконец !

-- 
Best regards,
Ed V. Bartosh

Re: [devel] Re: HIMEM up

[Anton Farygin]

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

Ed V. Bartosh пишет:
>  AF> Это было два дня назад. Дело не в том, что что у тебя
>  AF> плохие пакеты. Дело в том, что для сборки одних пакетов
>  AF> требуются другие, а т.к. hasher не умеет сортировать
>  AF> порядок сборки (не его это работа), то возникает достаточно
>  AF> много проблем.
> 
>  AF> Далее - по отзывам LDV, на многие уже собранные пакеты не
>  AF> проходит sisyphus_check.
> 
>  AF> Я не к тому, что у тебя совсем все плохо - бывают ошибки у
>  AF> всех. Просто нам нужно поменять схему, по которой пакеты с
>  AF> ядрами попадают в sisyphus. Так сказать автоматизировать.
> 
> Предлагалась же действующая схема, насколько я понимаю. И не только
> для ядер, а более общая. Более того, предлагалось устранить в ней те 
> недочеты, на которые было указано:
> http://www.altlinux.ru/pipermail/devel/2003-August/014094.html
> 
> Предложение было оставлено без ответа. Почему, можно узнать ?

Время. Наверное. Собственно это было не предложение а константация факта.

Наши сервера похоже не готовы к установке sandman в текущем виде, но это 
точнее скажет ldv.
> 
> Результат все тот же - продолжаем изобретать велосипед с другой формой
> колес в надежде на более удобную езду. Но мы уже едем, ребята ! Ауу !
> Проснитесь, наконец !

Этот велосипед будет конвертироваться (и уже наверное конвертируется) в 
sandman одной командой. Нам работать надо, а не ждать пока Сергей с 
Димой придут к общему мнению и запустят эту систему.

В общем - работы будут продолжаться в этом направлении.. будет sandman - 
перейдем на него.. не будет - останемся на старой схеме, ибо она уже 
работает и при этом достаточно проста.

Rgds,
Rider

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

Re: [devel] Re: HIMEM up

[Ed V. Bartosh]

 >> Предлагалась же действующая схема, насколько я понимаю. И не только
 >> для ядер, а более общая. Более того, предлагалось устранить в ней те
 >> недочеты, на которые было указано:
 >> http://www.altlinux.ru/pipermail/devel/2003-August/014094.html
 >> Предложение было оставлено без ответа. Почему, можно узнать ?

 AF> Время. Наверное. Собственно это было не предложение а константация факта.
Я имел в виду предложение Сергея интегрировать fakeroot в sandman.
И общее предложение использовать sandman для сборки пакетов. 
Разве этого не было ?

 AF> Наши сервера похоже не готовы к установке sandman в текущем виде, но
 AF> это точнее скажет ldv.
Дело хозяйское, конечно. Но ответ как бы и не прозвучал. 
А предложение было. И не одно.

 >> Результат все тот же - продолжаем изобретать велосипед с другой
 >> формой
 >> колес в надежде на более удобную езду. Но мы уже едем, ребята ! Ауу !
 >> Проснитесь, наконец !

 AF> Этот велосипед будет конвертироваться (и уже наверное конвертируется)
 AF> в sandman одной командой. Нам работать надо, а не ждать пока Сергей с
 AF> Димой придут к общему мнению и запустят эту систему.
Нам нужно выработать решение и работать над его реализацией, а не
тратить время на изготовление ненужных вещей.

 AF> В общем - работы будут продолжаться в этом направлении.. будет sandman
 AF> - перейдем на него.. не будет - останемся на старой схеме, ибо она уже
 AF> работает и при этом достаточно проста.
Он сам по себе не появится. Сами по себе появляются только
многочисленные костыли или велосипеды с квадратными колесами. И
избавиться от них бывает ох как непросто. Привыкаешь, потому что. И
лень переделывать, да и жалко потраченого времени.

-- 
Best regards,
Ed V. Bartosh

Re: [devel] Re: HIMEM up

[Anton Farygin]

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

Ed V. Bartosh пишет:
>  >> Предлагалась же действующая схема, насколько я понимаю. И не только
>  >> для ядер, а более общая. Более того, предлагалось устранить в ней те
>  >> недочеты, на которые было указано:
>  >> http://www.altlinux.ru/pipermail/devel/2003-August/014094.html
>  >> Предложение было оставлено без ответа. Почему, можно узнать ?
> 
>  AF> Время. Наверное. Собственно это было не предложение а константация факта.
> Я имел в виду предложение Сергея интегрировать fakeroot в sandman.
> И общее предложение использовать sandman для сборки пакетов. 
> Разве этого не было ?

да. Но что я могу тут ответить? Этими вопросами у нас в первую очередь 
занимается Дима.

2LDV: Дим, что ты скажешь по этому поводу?

> 
>  AF> Наши сервера похоже не готовы к установке sandman в текущем виде, но
>  AF> это точнее скажет ldv.
> Дело хозяйское, конечно. Но ответ как бы и не прозвучал. 
> А предложение было. И не одно.

Еще раз: Дим, что скажешь ?

> 
>  >> Результат все тот же - продолжаем изобретать велосипед с другой
>  >> формой
>  >> колес в надежде на более удобную езду. Но мы уже едем, ребята ! Ауу !
>  >> Проснитесь, наконец !
> 
>  AF> Этот велосипед будет конвертироваться (и уже наверное конвертируется)
>  AF> в sandman одной командой. Нам работать надо, а не ждать пока Сергей с
>  AF> Димой придут к общему мнению и запустят эту систему.
> Нам нужно выработать решение и работать над его реализацией, а не
> тратить время на изготовление ненужных вещей.

Я не трачу на это время... я просто делаю то, что на мой взгляд будет 
быстрее. Решение по sandman, по моему, скоро не может быть принято. Для 
начала - нам просто не хватит ресурсов серверов.

Я мог бы еще озвучить мои собственные претензии к sandman (почему мне 
лично он не нравится), но это опять вызовет повтор обсуждения. Зачем?

Единственное: по моему мы все таки пришли к мнению, что sandman 
нереально использовать для разработки, т.к. нет возможности делать 
распределенные репозитарии. Но это как бы и не проблема sandman... это 
проблема CVS в целом.

Эд, напомню тебе - все что обсуждалось про sandman - касалось только 
_read only_ репозитария. RW репозитарий сделать сейчас не представляется 
возможным по многим причинам (часть из них - чисто техническая).

Т.е. - тебе придется в любом случае коммитить в два репозитария. Как бы 
мы не старались. Трудозатраты на переписывание CVS с целью добавить 
распределенные репозитарии - нереальны и неподъемны.

sandman плохо приспособлен для работы на слабых каналах. В этом вся 
проблема. Для kernel - мы ее решим (никому не составит труда скачать cvs 
ядерных пакетов?)

> 
>  AF> В общем - работы будут продолжаться в этом направлении.. будет sandman
>  AF> - перейдем на него.. не будет - останемся на старой схеме, ибо она уже
>  AF> работает и при этом достаточно проста.
> Он сам по себе не появится. Сами по себе появляются только
> многочисленные костыли или велосипеды с квадратными колесами. И
> избавиться от них бывает ох как непросто. Привыкаешь, потому что. И
> лень переделывать, да и жалко потраченого времени.

Да. И сделать его сможет только один человек - автор sandman.

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

Rgds,
Rider

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

Re: [devel] Re: HIMEM up

[Ed V. Bartosh]

 >> Я имел в виду предложение Сергея интегрировать fakeroot в sandman.
 >> И общее предложение использовать sandman для сборки пакетов. Разве
 >> этого не было ?

 AF> да. Но что я могу тут ответить? Этими вопросами у нас в первую очередь
 AF> занимается Дима.
Это я не лично тебе писал, скорее community.

 >>  >> Результат все тот же - продолжаем изобретать велосипед с другой
 >>  >> формой
 >>  >> колес в надежде на более удобную езду. Но мы уже едем, ребята ! Ауу !
 >>  >> Проснитесь, наконец !
 >>  AF> Этот велосипед будет конвертироваться (и уже наверное
 >> конвертируется)
 >>  AF> в sandman одной командой. Нам работать надо, а не ждать пока Сергей с
 >>  AF> Димой придут к общему мнению и запустят эту систему.
 >> Нам нужно выработать решение и работать над его реализацией, а не
 >> тратить время на изготовление ненужных вещей.

 AF> Я не трачу на это время... я просто делаю то, что на мой взгляд будет
 AF> быстрее. Решение по sandman, по моему, скоро не может быть
 AF> принято. Для начала - нам просто не хватит ресурсов серверов.
Не понимаю, почему это их не хватит, все равно же пакеты
пересобираются, какая разница где это будет происходить ?

 AF> Я мог бы еще озвучить мои собственные претензии к sandman (почему мне
 AF> лично он не нравится), но это опять вызовет повтор обсуждения. Зачем?
Это обсуждение затихнет так же как и предыдущее, я тоже не вижу смысла
сотрясать воздух.

 AF> Эд, напомню тебе - все что обсуждалось про sandman - касалось только
 AF> _read only_ репозитария. RW репозитарий сделать сейчас не
 AF> представляется возможным по многим причинам (часть из них - чисто
 AF> техническая).

 AF> Т.е. - тебе придется в любом случае коммитить в два репозитария. Как
 AF> бы мы не старались. Трудозатраты на переписывание CVS с целью добавить
 AF> распределенные репозитарии - нереальны и неподъемны.
Ничего мне не придется. я как собирал здесь, так и буду продолжать. Не
вижу смысла делать одну и ту же работу 2 раза.

 AF> sandman плохо приспособлен для работы на слабых каналах. В этом вся
 AF> проблема. Для kernel - мы ее решим (никому не составит труда скачать
 AF> cvs ядерных пакетов?)
Никто пока и не заикался о его использовании на слабых каналах.

 >>  AF> В общем - работы будут продолжаться в этом направлении.. будет
 >> sandman
 >>  AF> - перейдем на него.. не будет - останемся на старой схеме, ибо она уже
 >>  AF> работает и при этом достаточно проста.
 >> Он сам по себе не появится. Сами по себе появляются только
 >> многочисленные костыли или велосипеды с квадратными колесами. И
 >> избавиться от них бывает ох как непросто. Привыкаешь, потому что. И
 >> лень переделывать, да и жалко потраченого времени.

 AF> Да. И сделать его сможет только один человек - автор sandman.
Возможно. А он разве против ? Что-то я не наблюдаю этого.

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

-- 
Best regards,
Ed V. Bartosh

Re: [devel] Re: HIMEM up

[Anton Farygin]

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

Ed V. Bartosh пишет:
>  >> Я имел в виду предложение Сергея интегрировать fakeroot в sandman.
>  >> И общее предложение использовать sandman для сборки пакетов. Разве
>  >> этого не было ?
> 
>  AF> да. Но что я могу тут ответить? Этими вопросами у нас в первую очередь
>  AF> занимается Дима.
> Это я не лично тебе писал, скорее community.
> 
>  >>  >> Результат все тот же - продолжаем изобретать велосипед с другой
>  >>  >> формой
>  >>  >> колес в надежде на более удобную езду. Но мы уже едем, ребята ! Ауу !
>  >>  >> Проснитесь, наконец !
>  >>  AF> Этот велосипед будет конвертироваться (и уже наверное
>  >> конвертируется)
>  >>  AF> в sandman одной командой. Нам работать надо, а не ждать пока Сергей с
>  >>  AF> Димой придут к общему мнению и запустят эту систему.
>  >> Нам нужно выработать решение и работать над его реализацией, а не
>  >> тратить время на изготовление ненужных вещей.
> 
>  AF> Я не трачу на это время... я просто делаю то, что на мой взгляд будет
>  AF> быстрее. Решение по sandman, по моему, скоро не может быть
>  AF> принято. Для начала - нам просто не хватит ресурсов серверов.
> Не понимаю, почему это их не хватит, все равно же пакеты
> пересобираются, какая разница где это будет происходить ?

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

> 
>  AF> Я мог бы еще озвучить мои собственные претензии к sandman (почему мне
>  AF> лично он не нравится), но это опять вызовет повтор обсуждения. Зачем?
> Это обсуждение затихнет так же как и предыдущее, я тоже не вижу смысла
> сотрясать воздух.

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

> 
>  AF> Эд, напомню тебе - все что обсуждалось про sandman - касалось только
>  AF> _read only_ репозитария. RW репозитарий сделать сейчас не
>  AF> представляется возможным по многим причинам (часть из них - чисто
>  AF> техническая).
> 
>  AF> Т.е. - тебе придется в любом случае коммитить в два репозитария. Как
>  AF> бы мы не старались. Трудозатраты на переписывание CVS с целью добавить
>  AF> распределенные репозитарии - нереальны и неподъемны.
> Ничего мне не придется. я как собирал здесь, так и буду продолжать. Не
> вижу смысла делать одну и ту же работу 2 раза.

Дело в том, что в определенный момент (когда схема будет отработана) 
пакеты в Sisyphus, содержащие kernel- будет просто некому забирать. А 
попадать они в Sisyphus будут из сборочного скрипта из CVS.

> 
>  AF> sandman плохо приспособлен для работы на слабых каналах. В этом вся
>  AF> проблема. Для kernel - мы ее решим (никому не составит труда скачать
>  AF> cvs ядерных пакетов?)
> Никто пока и не заикался о его использовании на слабых каналах.

А как тогда нам его поднять ? (я выше описал проблему)

> 
>  >>  AF> В общем - работы будут продолжаться в этом направлении.. будет
>  >> sandman
>  >>  AF> - перейдем на него.. не будет - останемся на старой схеме, ибо она уже
>  >>  AF> работает и при этом достаточно проста.
>  >> Он сам по себе не появится. Сами по себе появляются только
>  >> многочисленные костыли или велосипеды с квадратными колесами. И
>  >> избавиться от них бывает ох как непросто. Привыкаешь, потому что. И
>  >> лень переделывать, да и жалко потраченого времени.
> 
>  AF> Да. И сделать его сможет только один человек - автор sandman.
> Возможно. А он разве против ? Что-то я не наблюдаю этого.

Ну так пускай делает, если никто не возражает... но вот тот, кто это 
будет устанавливать, запускать и потом с этим работать - пока молчит. 
2ldv: что молчишь ?

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

Да. Добавляю еще одно CC на ldv@altlinux.com

Rgds,
Rider

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

Re: [devel] Re: HIMEM up

[Dmitry V. Levin]

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

On Thu, Aug 14, 2003 at 07:10:40PM +0400, Anton Farygin wrote:
> Ну так пускай делает, если никто не возражает... но вот тот, кто это 
> будет устанавливать, запускать и потом с этим работать - пока молчит. 
> 2ldv: что молчишь ?

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



-- 
ldv

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

[devel] Re: HIMEM up

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 380 bytes --]

On Thu, Aug 14, 2003 at 09:02:56AM +0400, Anton Farygin wrote:
> Далее - по отзывам LDV, на многие уже собранные пакеты не
> проходит sisyphus_check.

Я извиняюсь... вот моя кривулина-заливалка, у которой есть как
минимум два достоинства -- она дергает sisyphus_check и ведет
логи.

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

[-- Attachment #1.2: 2bte.sh --]
[-- Type: text/plain, Size: 701 bytes --]

#!/bin/sh
UPROOT=~/Upload
TARGET=incoming:/incoming/Sisyphus/BTE/
MAINTAINER=mike@inmetex.com.ua
SUBJ1="upload failed"
SUBJ2="gpg sig failed"
#. ~/.ssh/ssh-agent.sh 2>/dev/null 1>&2
#ssh-add

LC_ALL=C sisyphus_check "$UPROOT/BTE/" || exit 1

[ -z "$UPROOT/BTE/*.rpm" ] && exit 0
for i in $UPROOT/BTE/*.rpm; do
	rpm --checksig $i | grep -q gpg || {
#		echo "$i: GPG signature missing/invalid" | mail -s "$SUBJ2" $MAINTAINER
		echo "$i: GPG signature missing/invalid, skipping!" >&2
		continue
	}
	/usr/bin/rsync $* -avut --partial --stats \
		-e ssh $i $TARGET \
		>> $UPROOT/rsync-upload.log 2>&1 \
	&& mv $i $UPROOT/done \
	|| echo "upload failed: $i" | mail -s "$SUBJ1" $MAINTAINER
done
#ssh-add -D

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

Re: [d-kernel] Re: [devel] Re: HIMEM up

[Michael Shigorin]

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

On Wed, Aug 13, 2003 at 07:46:54PM +0400, Anton Farygin wrote:
> >У меня другой вопрос -- нет ли у уважаемых kernel flavour
> >maintainers видения того, какие ядра нужны?
[skip]

> supermount я поддерживать отказываюсь в каком ли бо виде.
> Это не мультимедийно-столовое, а полное багов. Т.е. - для самоубийц.

Мнению Сережи Рябчуна и Леши Морозова по этой теме я доверяю.

"Для самоубийц" по такой шкале глючности получаются AL[MJ]2.[02].

Тебя _заставлять_ поддерживать что-либо я не собираюсь -- это
было для других майнтейнеров.

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

Жизнь такая.

> Ага... мы сделали технологию размножения ядер... только не надо
> говорить: "Плодитесь"

Да, разумеется.  Я ж и пытаюсь собрать _назад_ ветки вдоль
осмысленных (IMHO) направлений и не предлагаю всем немедленно
этим и заниматься.

-- 
Миша

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

[devel] Re: [d-kernel] Re: HIMEM up

[Ed V. Bartosh]

>>>>> "MS" == Michael Shigorin writes:

 MS>   On Wed, Aug 13, 2003 at 04:42:42PM +0300, Andy Gorev wrote:
 >>  Существует-ли какая-либо обоснованная причина отсутствия
 >>  поддержки HIMEM в std-up ядре? Если не существует, или это
 >>  решаемо, то добавте пожалуйста CONFIG_HIGHMEM4G=y Ставить SMP не
 >>  предлагать ;-) ps подобная просьба звучит периодически и в
 >>  комьюнити и в сизифе
  
 MS>  Что характерно, там же звучит обоснование, почему _сейчас_ так
 MS>  уже не делается и почему предлагают ставить SMP или собирать
 MS>  свое.
А можно линк, я видимо пропустил.
  
 MS>  У меня другой вопрос -- нет ли у уважаемых kernel flavour
 MS>  maintainers видения того, какие ядра нужны?
  
 MS>  Пока предлагаю свои соображения:
  
 MS>  - std: default.  То, что должно быть при отсутствии других
 MS>    соображений, штатным, поддерживаемым etc.  То, что "в общем
 MS>    случае" должно просто работать.
  
 MS>  - aw: server default.  Думаю, объяснять, что фокус сборки и
 MS>    поддержки серверного ядра достаточно сильно отличается от
 MS>    "общих" и тем более "столовых" соображений.
Я уже прелагал, повторюсь - нужно это ядро переименовать в, скажем,
srv или что-нибудь другое более информативное.
  
 MS>  - "mm"/"ws": нечто более мультимедийно-столовое, которое может
 MS>    позволить себе включать не очень проверенные драйверы нового
 MS>    железа, патчи вроде win4lin, lowlat, supermount или пяток
 MS>    версий NVIDIA, но зато работать на всем, что горит и быть
 MS>    более приемлемым решением вопроса, чем "соберите сами", по тем
 MS>    флангам, где "тенденция, однако" (как w4l или sm).

А зачем ограничивать себя такими жесткими рамками ? 
Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то причины ?

-- 
Best regards,
Ed V. Bartosh

[devel] Re: [d-kernel] Re: HIMEM up

[Michael Shigorin]

On Thu, Aug 14, 2003 at 03:06:54PM +0400, Ed V. Bartosh wrote:
>  MS>  Что характерно, там же звучит обоснование, почему _сейчас_ так
>  MS>  уже не делается и почему предлагают ставить SMP или собирать
>  MS>  свое.
> А можно линк, я видимо пропустил.

Это в sisyphus@/community@.  SMP собирается с HIMEM.
Ссылку не дам -- без search.altlinux.ru и мне плохо ;-/

>  MS>  - aw: server default.  Думаю, объяснять, что фокус сборки и
> Я уже прелагал, повторюсь - нужно это ядро переименовать в,
> скажем, srv или что-нибудь другое более информативное.

Это не ко мне, хотя видимо. :)

>  MS>  - "mm"/"ws": нечто более мультимедийно-столовое, которое может
>  MS>    позволить себе включать не очень проверенные драйверы нового
>  MS>    железа, патчи вроде win4lin, lowlat, supermount или пяток
>  MS>    версий NVIDIA, но зато работать на всем, что горит и быть
>  MS>    более приемлемым решением вопроса, чем "соберите сами", по тем
>  MS>    флангам, где "тенденция, однако" (как w4l или sm).
> А зачем ограничивать себя такими жесткими рамками ? 

А кто сказал "ограничивать"? :)  Это скорее разграфка того, на
чем мне видится смысл концентрации усилий.  Экзотик-то много
может быть, но необязательно в Siysphus IMHO.

> Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то
> причины ?

Чтобы облегчить еще и проблему выбора пользователям и их
администраторам.

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

[devel] Re: [d-kernel] Re: HIMEM up

[Anton Farygin]

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

Michael Shigorin пишет:
> On Thu, Aug 14, 2003 at 03:06:54PM +0400, Ed V. Bartosh wrote:
> 
>> MS>  Что характерно, там же звучит обоснование, почему _сейчас_ так
>> MS>  уже не делается и почему предлагают ставить SMP или собирать
>> MS>  свое.
>>А можно линк, я видимо пропустил.

<skip>
> 
>>Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то
>>причины ?
> 
> 
> Чтобы облегчить еще и проблему выбора пользователям и их
> администраторам.
> 

Нет, что бы усложнить выбор пользователям. Всегда сложно сделать выбор, 
когда предложений слишком много ;-)

Особенно такой:

kernel-image-std-up
kernel-image-aw-up
kernel-image-w4l-up
kernel-image-llc-up

Можно к этому еще добавить (что бы окончательно запугать пользователя 
количеством ядер ;-) ):
kernel-image-dsa-up
kernel-image-rid-up
kernel-image-sup-up
kernel-image-svr-up
kernel-image-oem-up
kernel-image-dada-up
kernel-image-gmp-up
kernel-image-nbk-up
kernel-image-rsbac-up
kernel-image-owl-up

Выбор - мало не покажется  ;-)

Хотя я, в принципе, не возражаю - все равно std-up используется для 
дистрибутива для рабочей станции и инсталятора ;-)

Пока место есть на дисках - можно клепать.

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

Rgds,
Rider

P.S.
/me сделал :
  ls -al kernel-modules-*-std-up*|wc -l
      10
И умножил это на приведенный выше список ядер.... поплохело ;-)
140 пакетов с модулями ... при этом гарантированно не все пакеты с 
модулями будут для всех ядер.

P.P.S.
  /me вспомнил еще про smp и умножил на два ;-)))



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

[devel] Re: [d-kernel] Re: HIMEM up

[Anton Farygin]

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

Anton Farygin пишет:
> Michael Shigorin пишет:
<skip>
> 
> Rgds,
> Rider
> 
> P.S.
> /me сделал :
>  ls -al kernel-modules-*-std-up*|wc -l
>      10
> И умножил это на приведенный выше список ядер.... поплохело ;-)
> 140 пакетов с модулями ... при этом гарантированно не все пакеты с 
> модулями будут для всех ядер.
> 
> P.P.S.
>  /me вспомнил еще про smp и умножил на два ;-)))

P.P.S.

Пришел AEN, сказал про IA64, Athlon, AMD64, оптимизацию под пень 4 и мне 
поплохело еще в четыре раза, умноженное на smp ;-)

Шутка это конечно все, но в каждой шутке.. сами понимаете ;-)

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

[devel] Re: [d-kernel] Re: HIMEM up

[Michael Shigorin]

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

On Thu, Aug 14, 2003 at 05:51:30PM +0400, Anton Farygin wrote:
> >>Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то
> >>причины ?
> >Чтобы облегчить еще и проблему выбора пользователям и их
> >администраторам.
> Нет, что бы усложнить выбор пользователям.

Погоди.  Чем?

> Всегда сложно сделать выбор, когда предложений слишком много
> ;-)

Я ж о чем и.

> Надо бы все-таки концепцию для ядер - сколько делать и зачем.

Отож бо.  И какие стоит помещать в sisyphus (критерии), а какие
-- нет.

> P.P.S.
>  /me вспомнил еще про smp и умножил на два ;-)))

$you помножь на {i[56]86,athlon} и забалдей... :-]

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

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

Re: [devel] Re: [d-kernel] Re: HIMEM up

[Vadim V. Zhytnikov]

Anton Farygin пишет:

> Michael Shigorin пишет:
> 
>> On Thu, Aug 14, 2003 at 03:06:54PM +0400, Ed V. Bartosh wrote:
>>
>>> MS>  Что характерно, там же звучит обоснование, почему _сейчас_ так
>>> MS>  уже не делается и почему предлагают ставить SMP или собирать
>>> MS>  свое.
>>> А можно линк, я видимо пропустил.
> 
> 
> <skip>
> 
>>
>>> Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то
>>> причины ?
>>
>>
>>
>> Чтобы облегчить еще и проблему выбора пользователям и их
>> администраторам.
>>
> 
> Нет, что бы усложнить выбор пользователям. Всегда сложно сделать выбор, 
> когда предложений слишком много ;-)
> 
> Особенно такой:
> 
> kernel-image-std-up
> kernel-image-aw-up
> kernel-image-w4l-up
> kernel-image-llc-up
> 
> Можно к этому еще добавить (что бы окончательно запугать пользователя 
> количеством ядер ;-) ):
> kernel-image-dsa-up
> kernel-image-rid-up
> kernel-image-sup-up
> kernel-image-svr-up
> kernel-image-oem-up
> kernel-image-dada-up
> kernel-image-gmp-up
> kernel-image-nbk-up
> kernel-image-rsbac-up
> kernel-image-owl-up
> 
> Выбор - мало не покажется  ;-)
> 

Ещё openmosix забыли ;)

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

[devel] Re: [d-kernel] Re: HIMEM up

[Ed V. Bartosh]

>>>>> "MS" == Michael Shigorin writes:

 >>  А зачем ограничивать себя такими жесткими рамками ?
  
 MS>  А кто сказал "ограничивать"? :) Это скорее разграфка того, на
 MS>  чем мне видится смысл концентрации усилий.  Экзотик-то много
 MS>  может быть, но необязательно в Siysphus IMHO.
А по-моему наоборот, чем больше будет разных вариантов сборок, тем
больше народу будет ими охвачено, соответственно больше тестеров и
больше девелоперов, больше фиксов, фич. Чем плохо-то ?
Это не должно быть самоцелью, если какая-то фича отсутствует, то,
конечно, лучше вставить ее в существующее ядро, чем только ради этого
делать отдельное. Но потребности в данном случае разные бывают и
специально ограничивать набор ядер я бы не стал.
  
 >>  Чтобы incominger-aм жизнь облегчить ? Или еще есть какие-то
 >>  причины ?
  
 MS>  Чтобы облегчить еще и проблему выбора пользователям и их
 MS>  администраторам.
Было бы из чего выбирать :)

-- 
Best regards,
Ed V. Bartosh