[devel] Прототипы дизайна интерфейсов Кентавра

[devel] Прототипы дизайна интерфейсов Кентавра

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

Выложены прототипы дизайна интерфейсов следующей версии дистрибутива ALT Linux 
с кодовым именем Кентавр: 

http://www.altlinux.org/ALTLinux_6.0_Centaurus#Screenshots

Дизайн кентавра обсуждаем! поэтому не говорите, что никто не прислушивается к 
мнению сообщества по такой животрепещущей теме, как дизайн дистрибутива!

P.S. Прошу прощения за кросс-пост в community@ и devel@

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

Re: [devel] Прототипы дизайна интерфейсов Кентавра

[Igor Zubkov]

29 июля 2010 г. 15:18 пользователь Андрей Черепанов написал:
> Выложены прототипы дизайна интерфейсов следующей версии дистрибутива ALT Linux
> с кодовым именем Кентавр:
>
> http://www.altlinux.org/ALTLinux_6.0_Centaurus#Screenshots
>
> Дизайн кентавра обсуждаем! поэтому не говорите, что никто не прислушивается к
> мнению сообщества по такой животрепещущей теме, как дизайн дистрибутива!

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

Ну и по поводу прогресс-бара. Его бы заменить на что-то типа значка
"система занята" из jimmac темы курсоров. И да, это почти как в
MacOSX.

P.S.: и красная обоина тоже слишком яркая. будет отвлекать.

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Anton A. Vinogradov]

31.07.2010 14:12, Andrey Rahmatullin пишет:
> Точно, раз уж сервера на этом строить бесперспективно, а десктопа там не
> будет, то сделаем хотя бы красивую коробку!
Не в первый раз натыкаюсь на такого рода утверждения от участников ALT.

Насколько они отражают реальное положение дел?
в чем смысл подобных высказываний в сочетании с членством в Team?

-- 
С уважением,
Антон Виноградов
arc@

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Andrey Rahmatullin]

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

On Sat, Jul 31, 2010 at 02:17:16PM +0400, Anton A. Vinogradov wrote:
> > Точно, раз уж сервера на этом строить бесперспективно, а десктопа там не
> > будет, то сделаем хотя бы красивую коробку!
> Не в первый раз натыкаюсь на такого рода утверждения от участников ALT.
> 
> Насколько они отражают реальное положение дел?
Сейчас в бранчах сломан PHP и исправлять это никто не собирается.
Про соответствие заявленных сроков поддержки реальным лучше расскажет
thresh@, но, насколько я знаю, выпускать апдейты, в т.ч. по безопасности,
все забили.
Это лишь два примера.

> в чем смысл подобных высказываний в сочетании с членством в Team?
А что, молчать что ли?

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

> все-таки зачем российские физики используют слакварь?
Потому что _российские_ пьют много, а слакварь только спьяни использовать
можно :)
		-- mithraen in talk-room@

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

Re: [devel] [Comm] Бесперспективность vs Членство в TEAM (Прототипы дизайна интерфейсов Кентавра)

[Anton A. Vinogradov]

31.07.2010 14:26, Andrey Rahmatullin пишет:
> On Sat, Jul 31, 2010 at 02:17:16PM +0400, Anton A. Vinogradov wrote:
>>> Точно, раз уж сервера на этом строить бесперспективно, а десктопа там не
>>> будет, то сделаем хотя бы красивую коробку!
>> Не в первый раз натыкаюсь на такого рода утверждения от участников ALT.
>>
>> Насколько они отражают реальное положение дел?
> Сейчас в бранчах сломан PHP и исправлять это никто не собирается.
> Про соответствие заявленных сроков поддержки реальным лучше расскажет
> thresh@, но, насколько я знаю, выпускать апдейты, в т.ч. по безопасности,
> все забили.
> Это лишь два примера.
То-то и оно. Сам получил граблями от PHP.
>
>> в чем смысл подобных высказываний в сочетании с членством в Team?
> А что, молчать что ли?
Возможно, Вы просто подобрали не то слово, но от "бесперспективной" 
затеи следует немедленно отказываться.
Если "бесперспективность" однозначна и доказана.

Re: [devel] [Comm] Бесперспективность vs Членство в TEAM (Прототипы дизайна интерфейсов Кентавра)

[Andrey Rahmatullin]

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

On Sat, Jul 31, 2010 at 02:32:53PM +0400, Anton A. Vinogradov wrote:
> >> в чем смысл подобных высказываний в сочетании с членством в Team?
> > А что, молчать что ли?
> Возможно, Вы просто подобрали не то слово, но от "бесперспективной" 
> затеи следует немедленно отказываться.
Мне всё ещё влом переустанавливать ОС на десктопе.

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

<doc-work> Voins, "Затачиваю пальцы под vim/emacs по желанию заказчика.
           Быстро, качественно, недорого" Спросить doc'а

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

Re: [devel] Прототипы дизайна интерфейсов Кентавра

[Max Ivanov]

> Дизайн кентавра обсуждаем! поэтому не говорите, что никто не прислушивается к
> мнению сообщества по такой животрепещущей теме, как дизайн дистрибутива!
>

Alterator в таком оформлении выглядит чужим,тогда уж и Qt тему свою
рисовать надо

Re: [devel] Прототипы дизайна интерфейсов Кентавра

[Alexey I. Froloff]

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

On Sat, Jul 31, 2010 at 02:39:32PM +0100, Max Ivanov wrote:
> Alterator в таком оформлении выглядит чужим,тогда уж и Qt тему
> свою рисовать надо
Я двачую это.

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

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

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Anton Farygin]

31.07.2010 14:26, Andrey Rahmatullin пишет:
> On Sat, Jul 31, 2010 at 02:17:16PM +0400, Anton A. Vinogradov wrote:
>>> Точно, раз уж сервера на этом строить бесперспективно, а десктопа там не
>>> будет, то сделаем хотя бы красивую коробку!
>> Не в первый раз натыкаюсь на такого рода утверждения от участников ALT.
>>
>> Насколько они отражают реальное положение дел?
> Сейчас в бранчах сломан PHP и исправлять это никто не собирается.
> Про соответствие заявленных сроков поддержки реальным лучше расскажет
> thresh@, но, насколько я знаю, выпускать апдейты, в т.ч. по безопасности,
> все забили.
> Это лишь два примера.

А кто сказал, что в 6.0 PHP будет сломан и не будет поддерживаться ?

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Andrey Rahmatullin]

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

On Tue, Aug 03, 2010 at 10:20:09AM +0400, Anton Farygin wrote:
> >>> Точно, раз уж сервера на этом строить бесперспективно, а десктопа там не
> >>> будет, то сделаем хотя бы красивую коробку!
> >> Не в первый раз натыкаюсь на такого рода утверждения от участников ALT.
> >> Насколько они отражают реальное положение дел?
> > Сейчас в бранчах сломан PHP и исправлять это никто не собирается.
> > Про соответствие заявленных сроков поддержки реальным лучше расскажет
> > thresh@, но, насколько я знаю, выпускать апдейты, в т.ч. по безопасности,
> > все забили.
> > Это лишь два примера.
> А кто сказал, что в 6.0 PHP будет сломан и не будет поддерживаться ?
Не PHP, так что-нибудь другое.

-- 
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: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

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

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

On Tue, Aug 03, 2010 at 10:20:09AM +0400, Anton Farygin wrote:

AF> А кто сказал, что в 6.0 PHP будет сломан и не будет поддерживаться ?

Сломан -- не будет. А через сколько времени после выхода 6.0 ты на него
забьешь и перейдешь на Сизиф? :)

Это и есть ответ на вопрос о том, как будет поддерживаться PHP в 6.0.

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

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

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

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Anton Farygin]

03.08.2010 15:54, Денис Смирнов пишет:
> On Tue, Aug 03, 2010 at 10:20:09AM +0400, Anton Farygin wrote:
>
> AF>  А кто сказал, что в 6.0 PHP будет сломан и не будет поддерживаться ?
>
> Сломан -- не будет. А через сколько времени после выхода 6.0 ты на него
> забьешь и перейдешь на Сизиф? :)

Планирую сидеть на нём до выхода следующей LTS ветки, так что...

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

>
> Это и есть ответ на вопрос о том, как будет поддерживаться PHP в 6.0.

Нормально. Если, конечно, больше ничего не разломают...

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Slava Semushin]

3 августа 2010 г. 23:53 пользователь Anton Farygin <rider@altlinux.com> написал:
[...]
> Опять же - если я забью, то он там уже в любом случае будет собран нормально
> и бэкпортить станет намного проще.

Тут зависит от того кто как определяет "забил" мэйнтейнер на пакет или
нет. Скажем, кто-то из пользователей, вероятно, может считать, что РНР
в Сизифе поддерживается и мэйнтейнер за ним следит. Я же смотрю, что
вышел 5.3, который как бы нужен, но его у нас нет. И даже тот 5.2
который есть не самый последний (отстаёт по версии, последняя сборка
от марта этого года). (Сразу уточню: РНР последней версии не
обязателен, если все security-фиксы приложены.)

Если в 6.0 РНР будет таким же "поддерживаемым", то с моей точки зрения
РНР будет заброшен.

-- 
Slava Semushin

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Anton Farygin]

03.08.2010 21:18, Slava Semushin пишет:
> 3 августа 2010 г. 23:53 пользователь Anton Farygin<rider@altlinux.com>  написал:
> [...]
>> Опять же - если я забью, то он там уже в любом случае будет собран нормально
>> и бэкпортить станет намного проще.
>
> Тут зависит от того кто как определяет "забил" мэйнтейнер на пакет или
> нет. Скажем, кто-то из пользователей, вероятно, может считать, что РНР
> в Сизифе поддерживается и мэйнтейнер за ним следит. Я же смотрю, что
> вышел 5.3, который как бы нужен, но его у нас нет. И даже тот 5.2
> который есть не самый последний (отстаёт по версии, последняя сборка
> от марта этого года). (Сразу уточню: РНР последней версии не
> обязателен, если все security-фиксы приложены.)

php 5.2 планирую обновить на днях.

php-5.3 пока не готов, но к 6.0 планирую его собрать.

>
> Если в 6.0 РНР будет таким же "поддерживаемым", то с моей точки зрения
> РНР будет заброшен.

Не всё хорошо то, что новое.. можно долго спорить о том или ином, но 
текущий php в сизифе работает, и работает неплохо. А вот на 5.3 мой 
проект не работает, но миграция уже идёт...

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

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

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

On Tue, Aug 03, 2010 at 10:40:27PM +0400, Anton Farygin wrote:

AF> Не всё хорошо то, что новое.. можно долго спорить о том или ином, но 
AF> текущий php в сизифе работает, и работает неплохо. А вот на 5.3 мой 
AF> проект не работает, но миграция уже идёт...

Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
поддержку нескольких веток PHP? ;)

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

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

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

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Alexey Gladkov]

On 04.08.2010 10:00, Денис Смирнов wrote:
> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
> поддержку нескольких веток PHP? ;)

Оно так было очень давно.

-- 
Rgrds, legion

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Anton Farygin]

04.08.2010 10:00, Денис Смирнов пишет:
> On Tue, Aug 03, 2010 at 10:40:27PM +0400, Anton Farygin wrote:
>
> AF>  Не всё хорошо то, что новое.. можно долго спорить о том или ином, но
> AF>  текущий php в сизифе работает, и работает неплохо. А вот на 5.3 мой
> AF>  проект не работает, но миграция уже идёт...
>
> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
> поддержку нескольких веток PHP? ;)

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

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Sergey Kurakin]

On 08/04/2010 10:00 AM, Денис Смирнов wrote:
> On Tue, Aug 03, 2010 at 10:40:27PM +0400, Anton Farygin wrote:
> 
> AF> Не всё хорошо то, что новое.. можно долго спорить о том или ином, но 
> AF> текущий php в сизифе работает, и работает неплохо. А вот на 5.3 мой 
> AF> проект не работает, но миграция уже идёт...
> 
> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
> поддержку нескольких веток PHP? ;)

  А это действительно надо?

  Схема, построенная legion@, вполне позволяет держать несколько
веток php не только в репозитории, но и в системе.

  А с ума я сходил, вот мой эскизный набросок:

http://git.altlinux.org/people/kurakin/packages/?p=php53.git;a=summary

  Во вчерашнем разговоре с rider@ мы сошлись на том, что вряд ли две
ветки php практически оправданы сейчас. Но если у вас другое мнение,
то давайте обсудим. Практически это вполне возможно и даже не так уж
и сложно, благодаря схеме Алексея.

  Здесь ситуация такая: теоретически могу допилить php53 (5.3.3) и
выложить его в Сизиф рядом с php5 (5.2.14). Но я понимаю, что моя
сборка будет заведомо хуже и по качеству и по поддержке, чем та 5.3,
которую к осени собирается делать Антон взамен 5.2.

-- 
WBR,
Sergey Kurakin

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

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

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

On Wed, Aug 04, 2010 at 10:20:08AM +0400, Alexey Gladkov wrote:

AG> Оно так было очень давно.

Было только major, насколько я помню (php4/php5). А php5.2/php5.3?

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

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

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

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Alexey Gladkov]

On 05.08.2010 00:56, Денис Смирнов wrote:
> On Wed, Aug 04, 2010 at 10:20:08AM +0400, Alexey Gladkov wrote:
> 
> AG> Оно так было очень давно.
> 
> Было только major, насколько я помню (php4/php5). А php5.2/php5.3?

Это совершенно не проблема.

Для простоты можно оставить имена макросов одинаковыми у
rpm-build-php5.{2,3} и поставить конфликты между ними. Тут есть минус,
когда захочется собирать из одного спека модуль под оба php сразу.

-- 
Rgrds, legion

[devel] grub, alterator-vm (was: [Comm] Прототипы дизайна интерфейсов Кентавра)

[Michael Shigorin]

On Thu, Aug 05, 2010 at 01:08:01AM +0400, Aleksey Novodvorsky wrote:
> >> требуется помощь в [...] переписывании alterator-vm без evms
> >> (для работы Grub) [...]
> > Полагаю, подумать ещё раз и отказаться от grub будет более
> > здравой идеей на данном этапе.
> > Ну и /vm пользуется libevms, а не самим evms, насколько помню.
> Михаил, думаю что это не для community@

Да, промазал.

К задачке хотя бы простенькой морды к *fdisk/mdadm/lvm
приценивался, это совсем не дело пары месяцев даже для
более шаблонизируемых случаев, чем общий.

OTOH надо бы проверить/подновить alterator-vm в свете
4k-дисков (http://www.altlinux.org/BigSector и
https://bugzilla.altlinux.org/show_bug.cgi?id=16000),
сизифный всё так же отбивает разделы с 63-го сектора
и не align'ит на что-либо кроме мифического цилиндра.

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

[devel] security updates, long-term

[Michael Shigorin]

On Sat, Jul 31, 2010 at 04:26:38PM +0600, Andrey Rahmatullin wrote:
> Сейчас в бранчах сломан PHP и исправлять это никто не собирается.

Зачем говорить о "будущем выпуске" и "сейчас в бранчах", зная,
что они к нему ни при чём?  Форменное передёргивание.

Для 6.0/branch на него пока виды неплохие (хотя и не шикарные).

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

Не все и не совсем, но системной работы сейчас не ведётся.
Для неё требуется:

- внятный серверный дистрибутив, который окажется полезен;
- создать updates/6.0 и не отсылать за апдейтами в бранч;
- набирать main как для ALS4.0 -- "кто что берётся поддерживать";
- искать человека на фултайм в качестве security response engineer
  и "подпирать" им случаи нужного для сервера софта, который никто
  не берётся поддерживать в должной мере (а также для ситуаций,
  когда майнтейнер есть и работает, но в отпуске или на даче);
- координировать работы по выпуску необходимых обновлений.

Проблемен в основном пункт про человека, причём однажды его уже
искали и найти не смогли.  Требуется от него во многом усидчивость
и аккуратность, не ueberhacker'ство.  Ну и надеюсь, что до времени
выпуска LTS-дистрибутива оргвопросы также получится решить.

И ещё надо публично объявлять решение о сворачивании выпуска
обновлений раньше предварительно озвученного срока либо о том,
что меняется источник получения обновлений (как произошло с
updates/4.0 -> 4.0/branch по факту).  Да, это стыдно, но надо,
если уж иначе никак.

> > в чем смысл подобных высказываний в сочетании с членством в Team?
> А что, молчать что ли?

Понимаешь, ругаться можно конструктивно, а можно просто ядовито.
У нас совершенно шикарно плевался ядом adiel@, когда допекало.
Только меру знал и делал всегда очень много.

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

Re: [devel] security updates, long-term

[Andrey Rahmatullin]

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

On Thu, Aug 05, 2010 at 09:27:21AM +0300, Michael Shigorin wrote:
> > Сейчас в бранчах сломан PHP и исправлять это никто не собирается.
> Зачем говорить о "будущем выпуске" и "сейчас в бранчах", зная,
> что они к нему ни при чём?  Форменное передёргивание.
Тенденция.

> Для 6.0/branch на него пока виды неплохие (хотя и не шикарные).
> 
> > Про соответствие заявленных сроков поддержки реальным лучше
> > расскажет thresh@, но, насколько я знаю, выпускать апдейты,
> > в т.ч. по безопасности, все забили.
> Не все и не совсем, но системной работы сейчас не ведётся.
> Для неё требуется:
> 
> - внятный серверный дистрибутив, который окажется полезен;
> - создать updates/6.0 и не отсылать за апдейтами в бранч;
> - набирать main как для ALS4.0 -- "кто что берётся поддерживать";
> - искать человека на фултайм в качестве security response engineer
>   и "подпирать" им случаи нужного для сервера софта, который никто
>   не берётся поддерживать в должной мере (а также для ситуаций,
>   когда майнтейнер есть и работает, но в отпуске или на даче);
> - координировать работы по выпуску необходимых обновлений.
Ну. А LTS тем не менее заявлен, и заявлен давно, и сомнения про это уже
давно высказываются.

> > > в чем смысл подобных высказываний в сочетании с членством в Team?
> > А что, молчать что ли?
> Понимаешь, ругаться можно конструктивно, а можно просто ядовито.
А я один это всё не починю.
Я честно пытался сделать нам debug packages и считаю процесс и результат
довольно показательным примером. Поэтому сейчас я в maintenance mode в
смысле сборки только того, что непосредственно используется мной.

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

> Давно хотел спросить - по выходным у смотрелки [в /incoming] выходной? =)
Нет, смотрелка работает круглосуточно в автономном режиме.
Но у запускальщика собиралки по выходным действительно выходной.
:)
		-- ldv in devel@

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

Re: [devel] security updates, long-term

[Michael Shigorin]

On Thu, Aug 05, 2010 at 12:35:15PM +0600, Andrey Rahmatullin wrote:
> > Зачем говорить о "будущем выпуске" и "сейчас в бранчах", зная,
> > что они к нему ни при чём?  Форменное передёргивание.
> Тенденция.

Тогда не стоило цитировать конкретику, ты-то квотишь не всё подряд.

> Ну. А LTS тем не менее заявлен, и заявлен давно, и сомнения про
> это уже давно высказываются.

Я этим возмущаюсь несильно потому, что оцениваю вероятность
решения оргвопросов по ставке для такого инженера как довольно
высокую до наступления следующего года.  То есть сейчас больше
беспокоит, кто бы из людей достаточно доверенных взялся за такую
работу (вероятно, удалёнку).

DISCLAIMER: это всего лишь высказывания человека, не принимающего
решения в ООО Альт Линукс, но старающегося содействовать по мере
сил и возможностей.

> > Понимаешь, ругаться можно конструктивно, а можно просто ядовито.
> А я один это всё не починю.

Конечно.

> Я честно пытался сделать нам debug packages и считаю процесс и
> результат довольно показательным примером.

Помнишь, как Витя Форсюк доооолго пытался сделать нам noarch
subpackages?  В итоге случилось, хоть и заняло гораздо больше
времени и слов, чем могло.

То же самое было и с BTE, и с ещё многими вещами и концепциями.
Всё-таки помогает запастись терпением и не отчаиваться сразу.
Проверено.

> Поэтому сейчас я в maintenance mode в смысле сборки только
> того, что непосредственно используется мной.

Ну я сейчас собираю поди меньше тебя, но настрой другой. :)

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

Re: [devel] security updates, long-term

[Alex Gorbachenko]

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

On Thu, 5 Aug 2010 09:44:15 +0300
Michael wrote:

>Всё-таки помогает запастись терпением и не отчаиваться сразу.
>Проверено.


но зачем ? значительно проще использовать то, где есть реальный
LTS/ядра/whatever. 

-- 
np: AC/DC - For Those About To Rock (We Salute You)

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

Re: [devel] security updates, long-term

[Andrey Rahmatullin]

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

On Thu, Aug 05, 2010 at 11:55:27AM +0400, Alex Gorbachenko wrote:
> >Всё-таки помогает запастись терпением и не отчаиваться сразу.
> >Проверено.
> но зачем ? значительно проще использовать то, где есть реальный
> LTS/ядра/whatever. 
+1

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

<Lost> гусев и багзилло - как лед и пламя
<thresh> а кто такой пламя?

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

Re: [devel] security updates, long-term

[Slava Semushin]

5 августа 2010 г. 14:58 пользователь Andrey Rahmatullin
<wrar@altlinux.org> написал:
> On Thu, Aug 05, 2010 at 11:55:27AM +0400, Alex Gorbachenko wrote:
>> >Всё-таки помогает запастись терпением и не отчаиваться сразу.
>> >Проверено.
>> но зачем ? значительно проще использовать то, где есть реальный
>> LTS/ядра/whatever.
> +1
+1 (хотя это и не патриотично)


-- 
Slava Semushin

Re: [devel] security updates, long-term

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

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

On Thu, Aug 05, 2010 at 11:55:27AM +0400, Alex Gorbachenko wrote:

AG> но зачем ? значительно проще использовать то, где есть реальный
AG> LTS/ядра/whatever. 

hasher, gear, параноидальные настройки из коробки  sshd и многих других
сервисов, mkimage, spt (для openvz), rpm с человечьим лицом.

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

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

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

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

Re: [devel] security updates, long-term

[Slava Semushin]

5 августа 2010 г. 19:14 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> On Thu, Aug 05, 2010 at 11:55:27AM +0400, Alex Gorbachenko wrote:
>
> AG> но зачем ? значительно проще использовать то, где есть реальный
> AG> LTS/ядра/whatever.

Денис, обрати внимание, что в процитированном было слово "использовать".

> hasher, gear,

Зачем это? Это нужно только разработчикам.

> параноидальные настройки из коробки  sshd и многих других
> сервисов,

sshd домашним пользователям обычно не нужен.

> mkimage, spt (для openvz),

Что это и зачем? Делать болванки со своим дистром? Это нужно лишь
небольшому проценту пользователей. Остальным это не надо (например, я
лишь по наслышке знаю что это).

> rpm с человечьим лицом.

Например. Ну что там человечьего?

(Кстати, недавно нашел письмо года 2005, о том что в мане не описана
опция --obsoletes. Всё никак не [сд]оберусь повесить баг.)


-- 
Slava Semushin

Re: [devel] security updates, long-term

[Slava Semushin]

5 августа 2010 г. 20:24 пользователь Slava Semushin
<slava.semushin@gmail.com> написал:
[...]
>> параноидальные настройки из коробки  sshd и многих других
>> сервисов,
>
> sshd домашним пользователям обычно не нужен.

P.S. А если вдруг сейчас придёт rider@ и скажет, что ему нужен sshd на
домашней машинке, то это не считается, т.к. Антон не обычный
пользователь ;) (даже если команда groups и причисляет его к users.)


-- 
Slava Semushin

Re: [devel] security updates, long-term

[Alex Gorbachenko]

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

On Thu, 5 Aug 2010 16:14:49 +0400
Денис wrote:

>hasher, gear, параноидальные настройки из коробки  sshd и многих других
>сервисов, mkimage, spt (для openvz), rpm с человечьим лицом.

средства сборки пакетов в пустом ридонли чруте есть у всех крупных
дистрибутивов. 

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

"человечье лицо" это несовместимость ни с чем, кроме себя самого ? да,
у остальных с этим есть определённые сложности. 

-- 
np: Eagles - Last Good Time In Town

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

Re: [devel] security updates, long-term

[Michael Shigorin]

On Thu, Aug 05, 2010 at 11:55:27AM +0400, Alex Gorbachenko wrote:
> >Всё-таки помогает запастись терпением и не отчаиваться сразу.
> >Проверено.
> но зачем ? значительно проще использовать то, где есть реальный
> LTS/ядра/whatever. 

Если всем устраивает -- то конечно, так и разумней.
(меня -- нет)

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

Re: [devel] security updates, long-term

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

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

On Thu, Aug 05, 2010 at 08:24:53PM +0700, Slava Semushin wrote:

SS> Денис, обрати внимание, что в процитированном было слово "использовать".

Смотря что называть "использованием".

Граница между "админом" и "разработчиком" -- в контексте сборки пакетов
весьма размыта.

>> hasher, gear,
SS> Зачем это? Это нужно только разработчикам.

Меня сейчас сложно назвать разработчиком. Но они мне нужны :)

SS> sshd домашним пользователям обычно не нужен.
SS> Что это и зачем? Делать болванки со своим дистром? Это нужно лишь
SS> небольшому проценту пользователей. Остальным это не надо (например, я
SS> лишь по наслышке знаю что это).
SS> Например. Ну что там человечьего?
SS> (Кстати, недавно нашел письмо года 2005, о том что в мане не описана
SS> опция --obsoletes. Всё никак не [сд]оберусь повесить баг.)

А! Мы говорим об обычном домашнем пользователе?

Увы, они мне не интересны. От того поставит ли кто-то у себя линукс дома
или нет -- мне ни холодно, ни жарко. Моя целевая аудитория -- админы.
Удобство их работы -- важно. И отсутствия к ним претензий от их
пользователей -- тоже важно.

А домашние пользователи, увы, пущай идут к Apple, 

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

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

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

Re: [devel] security updates, long-term

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

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

On Thu, Aug 05, 2010 at 05:39:24PM +0400, Alex Gorbachenko wrote:

>> hasher, gear, параноидальные настройки из коробки  sshd и многих других
>> сервисов, mkimage, spt (для openvz), rpm с человечьим лицом.
AG> средства сборки пакетов в пустом ридонли чруте есть у всех крупных
AG> дистрибутивов. 

У нас это еще и автоматизированная проверка качества.

Которая не пропускает редкостный мусор, который встречается, например, в
CentOS.

AG> средства для сборки своего дистрибутива точно есть в opensuse,
AG> подозреваю что и у остальных тоже.

И опубликованные профили дистрибутивов -- тоже?

AG> "человечье лицо" это несовместимость ни с чем, кроме себя самого ? да,
AG> у остальных с этим есть определённые сложности. 

Нет, это возможность собрать пакет человеку, а не биороботу.

Это еще и хороший поиск автозависимостей. Это и отсутствие ненужных
конструкций. Это и в целом ощущение красоты от спека.

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

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

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

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

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

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

On Wed, Aug 04, 2010 at 12:25:39PM +0400, Sergey Kurakin wrote:

>> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
>> поддержку нескольких веток PHP? ;)
SK>   А это действительно надо?

Надо, но только если эти ветки кто-нибудь будет реально поддерживать.

SK>   Схема, построенная legion@, вполне позволяет держать несколько
SK> веток php не только в репозитории, но и в системе.
SK>   А с ума я сходил, вот мой эскизный набросок:
SK> http://git.altlinux.org/people/kurakin/packages/?p=php53.git;a=summary
SK>   Во вчерашнем разговоре с rider@ мы сошлись на том, что вряд ли две
SK> ветки php практически оправданы сейчас. Но если у вас другое мнение,
SK> то давайте обсудим. Практически это вполне возможно и даже не так уж
SK> и сложно, благодаря схеме Алексея.

Смысл в том, что кто-то хочет более новую версию, а кто-то несовместим со
старой.

SK>   Здесь ситуация такая: теоретически могу допилить php53 (5.3.3) и
SK> выложить его в Сизиф рядом с php5 (5.2.14). Но я понимаю, что моя
SK> сборка будет заведомо хуже и по качеству и по поддержке, чем та 5.3,
SK> которую к осени собирается делать Антон взамен 5.2.

Я не знаю что сказать. Если это будет другая сборка, то лучше не надо.
Если Антон осенью просто допилит эту ветку -- тогда надо.

А осенью, это случай не после выхода кентавра уже будет? Если так -- точно
надо делать параллельно.

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

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

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

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

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

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

On Thu, Aug 05, 2010 at 01:27:47AM +0400, Alexey Gladkov wrote:

AG> Для простоты можно оставить имена макросов одинаковыми у
AG> rpm-build-php5.{2,3} и поставить конфликты между ними. Тут есть минус,
AG> когда захочется собирать из одного спека модуль под оба php сразу.

Я себе не очень представляю как это (и насколько это удобно). Собирать из
разных веток в одном gear-репо не лучше?

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

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

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

Re: [devel] [Comm] Прототипы дизайна интерфейсов Кентавра

[Alexey Gladkov]

On 07.08.2010 11:17, Денис Смирнов wrote:
> Я себе не очень представляю как это (и насколько это удобно). Собирать из
> разных веток в одном gear-репо не лучше?

Я не понял вопроса, но в любом случае как собирать это вопрос
удобства. Техническая возможность держать несколько php у нас есть.

-- 
Rgrds, legion

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Slava Dubrovskiy]

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

04.08.2010 09:20, Alexey Gladkov пишет:
> On 04.08.2010 10:00, Денис Смирнов wrote:
>   
>> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
>> поддержку нескольких веток PHP? ;)
>>     
> Оно так было очень давно.
>   
А расскажите пожалуйста, почему сборка php сделана именно так? 
1. Т. е. почему каждый sapi и ext собирается из своего srpm?
Например в дебиане и сборке от remi все собирается одномоментно. Это
позволяет избежать проблем, когда какое-то расширение не пересобрали с
новой версией (речь идет про те что поставляются с самим php, а не
сторонними). Также это упрощает поддержку пакета, бэкпорт. Не нужно
делать патч и выделять libphp и т.д.

2. Зачем конфиги располагаются в версийзависимых директориях?
Обновление php это просто ад. Приходится вручную проверять все изменения
и вносить их заново.

3. Зачем safe-mode включен по умолчанию? 
Я не могу припомнить не одной проги в репозитарии, которая бы работала с ним нормально.

И еще, несколько версий PHP обязательно нужны. И нужна возможность использовать их одновременно. Конечно, если есть желание чтобы АЛЬТ использовался в качестве веб платформы.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5525 bytes --]

Re: [devel] Умолчания PHP [was: PHP 5.3.3]

[Anton Farygin]

10.08.2010 13:49, Slava Dubrovskiy пишет:
> 04.08.2010 09:20, Alexey Gladkov пишет:
>> On 04.08.2010 10:00, Денис Смирнов wrote:
>>
>>> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
>>> поддержку нескольких веток PHP? ;)
>>>
>> Оно так было очень давно.
>>
> А расскажите пожалуйста, почему сборка php сделана именно так?
> 1. Т. е. почему каждый sapi и ext собирается из своего srpm?
> Например в дебиане и сборке от remi все собирается одномоментно. Это
> позволяет избежать проблем, когда какое-то расширение не пересобрали с
> новой версией (речь идет про те что поставляются с самим php, а не
> сторонними). Также это упрощает поддержку пакета, бэкпорт. Не нужно
> делать патч и выделять libphp и т.д.

у нас так устроена система сборки, что не пересобрать какое-то 
расширение с новой версией PHP просто невозможно.

Сборка каждого sapi и ext в отельном пакете _значительно_ упрощает 
сопровождение PHP, особенно когда ext мейнтенит не один человек, а 
несколько разных.

>
> 2. Зачем конфиги располагаются в версийзависимых директориях?
> Обновление php это просто ад. Приходится вручную проверять все изменения
> и вносить их заново.
>
> 3. Зачем safe-mode включен по умолчанию?
> Я не могу припомнить не одной проги в репозитарии, которая бы работала с ним нормально.

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

>
> И еще, несколько версий PHP обязательно нужны. И нужна возможность использовать их одновременно. Конечно, если есть желание чтобы АЛЬТ использовался в качестве веб платформы.

В этом утверждении есть ответ на вопрос номер 2.

Re: [devel] Умолчания PHP [was: PHP 5.3.3]

[Slava Dubrovskiy]

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

10.08.2010 13:33, Anton Farygin пишет:
> 10.08.2010 13:49, Slava Dubrovskiy пишет:
>> 04.08.2010 09:20, Alexey Gladkov пишет:
>>> On 04.08.2010 10:00, Денис Смирнов wrote:
>>>
>>>> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
>>>> поддержку нескольких веток PHP? ;)
>>>>
>>> Оно так было очень давно.
>>>
>> А расскажите пожалуйста, почему сборка php сделана именно так?
>> 1. Т. е. почему каждый sapi и ext собирается из своего srpm?
>> Например в дебиане и сборке от remi все собирается одномоментно. Это
>> позволяет избежать проблем, когда какое-то расширение не пересобрали с
>> новой версией (речь идет про те что поставляются с самим php, а не
>> сторонними). Также это упрощает поддержку пакета, бэкпорт. Не нужно
>> делать патч и выделять libphp и т.д.
>
> у нас так устроена система сборки, что не пересобрать какое-то
> расширение с новой версией PHP просто невозможно.
>
Ок. Раньше такое было.
>
> Сборка каждого sapi и ext в отельном пакете _значительно_ упрощает
> сопровождение PHP, особенно когда ext мейнтенит не один человек, а
> несколько разных.
Ой не могу согласиться. Например прикладывать патчи которые должны быть
в обоих srpm более трудоемко. Как показывает практика, бэкпортированием
мантейнер не занимается. И это приходится делать менее опытному
заинтересованному члену тиим. И такое количество пакетов и сама система
сборки отбивает всякое желание.
Про нескольких мантейнеров одного ext тоже не убедительно. Тут сам php
пол-года был без мантейнера. А вы говорите про целых двух или больше.

>
>>
>> 2. Зачем конфиги располагаются в версийзависимых директориях?
>> Обновление php это просто ад. Приходится вручную проверять все изменения
>> и вносить их заново.
>>
> В этом утверждении есть ответ на вопрос номер 2.
Да, не правильно спросил.
Но проблема остается. При каждом обновлении конфиги приходится проверять
и править вручную. pre и post скрипты не работают.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5525 bytes --]

Re: [devel] Умолчания PHP [was: PHP 5.3.3]

[Anton Farygin]

10.08.2010 16:20, Slava Dubrovskiy пишет:
> 10.08.2010 13:33, Anton Farygin пишет:
>> 10.08.2010 13:49, Slava Dubrovskiy пишет:
>>> 04.08.2010 09:20, Alexey Gladkov пишет:
>>>> On 04.08.2010 10:00, Денис Смирнов wrote:
>>>>
>>>>> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
>>>>> поддержку нескольких веток PHP? ;)
>>>>>
>>>> Оно так было очень давно.
>>>>
>>> А расскажите пожалуйста, почему сборка php сделана именно так?
>>> 1. Т. е. почему каждый sapi и ext собирается из своего srpm?
>>> Например в дебиане и сборке от remi все собирается одномоментно. Это
>>> позволяет избежать проблем, когда какое-то расширение не пересобрали с
>>> новой версией (речь идет про те что поставляются с самим php, а не
>>> сторонними). Также это упрощает поддержку пакета, бэкпорт. Не нужно
>>> делать патч и выделять libphp и т.д.
>>
>> у нас так устроена система сборки, что не пересобрать какое-то
>> расширение с новой версией PHP просто невозможно.
>>
> Ок. Раньше такое было.
>>
>> Сборка каждого sapi и ext в отельном пакете _значительно_ упрощает
>> сопровождение PHP, особенно когда ext мейнтенит не один человек, а
>> несколько разных.
> Ой не могу согласиться. Например прикладывать патчи которые должны быть
> в обоих srpm более трудоемко. Как показывает практика, бэкпортированием
> мантейнер не занимается. И это приходится делать менее опытному
> заинтересованному члену тиим. И такое количество пакетов и сама система
> сборки отбивает всякое желание.
> Про нескольких мантейнеров одного ext тоже не убедительно. Тут сам php
> пол-года был без мантейнера. А вы говорите про целых двух или больше.

Это реальность.

>
>>
>>>
>>> 2. Зачем конфиги располагаются в версийзависимых директориях?
>>> Обновление php это просто ад. Приходится вручную проверять все изменения
>>> и вносить их заново.
>>>
>> В этом утверждении есть ответ на вопрос номер 2.
> Да, не правильно спросил.
> Но проблема остается. При каждом обновлении конфиги приходится проверять
> и править вручную. pre и post скрипты не работают.

А в этих скриптах и нет ничего такого, что бы могло помочь.

У меня есть мысль, которую я уже давно думаю..

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

Re: [devel] Умолчания PHP [was: PHP 5.3.3]

[Dmitriy Kulik]

2010/8/10 Anton Farygin <rider@altlinux.com>:
> 10.08.2010 16:20, Slava Dubrovskiy пишет:
>>
>> 10.08.2010 13:33, Anton Farygin пишет:
>>>
>>> 10.08.2010 13:49, Slava Dubrovskiy пишет:
>>>>
>>>> 04.08.2010 09:20, Alexey Gladkov пишет:
>>>>>
>>>>> On 04.08.2010 10:00, Денис Смирнов wrote:
>>>>>
>>>>>> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас
>>>>>> поддержку нескольких веток PHP? ;)
>>>>>>
>>>>> Оно так было очень давно.
>>>>>
>>>> А расскажите пожалуйста, почему сборка php сделана именно так?
>>>> 1. Т. е. почему каждый sapi и ext собирается из своего srpm?
>>>> Например в дебиане и сборке от remi все собирается одномоментно. Это
>>>> позволяет избежать проблем, когда какое-то расширение не пересобрали с
>>>> новой версией (речь идет про те что поставляются с самим php, а не
>>>> сторонними). Также это упрощает поддержку пакета, бэкпорт. Не нужно
>>>> делать патч и выделять libphp и т.д.
>>>
>>> у нас так устроена система сборки, что не пересобрать какое-то
>>> расширение с новой версией PHP просто невозможно.
>>>
>> Ок. Раньше такое было.
>>>
>>> Сборка каждого sapi и ext в отельном пакете _значительно_ упрощает
>>> сопровождение PHP, особенно когда ext мейнтенит не один человек, а
>>> несколько разных.
>>
>> Ой не могу согласиться. Например прикладывать патчи которые должны быть
>> в обоих srpm более трудоемко. Как показывает практика, бэкпортированием
>> мантейнер не занимается. И это приходится делать менее опытному
>> заинтересованному члену тиим. И такое количество пакетов и сама система
>> сборки отбивает всякое желание.

Ну почему же отбивает. Наоборот довольно все просто. Через скрипт
пробежаться по всем гитам и для них сделать add_changelog
gear-create-tag и парочку остальных команд...

>> Про нескольких мантейнеров одного ext тоже не убедительно. Тут сам php
>> пол-года был без мантейнера. А вы говорите про целых двух или больше.
>
> Это реальность.
>
>>
>>>
>>>>
>>>> 2. Зачем конфиги располагаются в версийзависимых директориях?
>>>> Обновление php это просто ад. Приходится вручную проверять все изменения
>>>> и вносить их заново.
>>>>
>>> В этом утверждении есть ответ на вопрос номер 2.
>>
>> Да, не правильно спросил.
>> Но проблема остается. При каждом обновлении конфиги приходится проверять
>> и править вручную. pre и post скрипты не работают.
>
> А в этих скриптах и нет ничего такого, что бы могло помочь.
>
> У меня есть мысль, которую я уже давно думаю..
>
> отказаться от идеи ведения нескольких версий PHP в репозитории, ибо оно в
> принципе не так что бы очень актуально. При этом можно попробовать сделать
> один конфиг для PHP, без привязки к версиям, который не будет обновляться
> при установке новой версии.

Идея хорошая. Но нужно делать хотя-бы различие версий 5.2 5.3 6.x
потому-что они отличаются очень даже.

Re: [devel] Умолчания PHP [was: PHP 5.3.3]

[Sergey Kurakin]

On 10 August 2010, Anton Farygin wrote:
> 10.08.2010 13:49, Slava Dubrovskiy пишет:
> > 3. Зачем safe-mode включен по умолчанию?
> > Я не могу припомнить не одной проги в репозитарии, которая 
> > бы работала с ним нормально. 
> 
> Мне тоже приходится его постоянно отключать. Есть возражения 
> против того, что бы выключить его по умолчанию ?

  Поддерживаю. Safe-mode -- это все таки "песочница", кому она 
действительно нужна, тот сам включит. Причем через control(8).

  Давно уже собираюсь тщательно пройтись по php'шным control 
facilities, да всё руки не доходят. Может, сегодня получится.

-- 
WBR,
Sergey Kurakin

Re: [devel] Умолчания PHP [was: PHP 5.3.3]

[Sergey Kurakin]

On 10 August 2010, Anton Farygin wrote:
> 10.08.2010 16:20, Slava Dubrovskiy пишет:
> > Но проблема остается. При каждом обновлении конфиги 
> > приходится проверять 
> > и править вручную. pre и post скрипты не работают.
> 
> А в этих скриптах и нет ничего такого, что бы могло помочь.

  Как ни странно, нечто такое там есть. В пакете php-base есть 
скрипт phpini-migrate by legion@ (2006).

  Но запускать его из post я бы в любом случае не стал. По этой 
причине и не вчитывался...

  Думаю, что неплохим решением проблемы php.ini мог бы стать 
control(8). Посмотрю, что там и как.

  А вообще, необходимость каждый раз при смене версии 
просматривать php.ini -- это не только очень плохо, но еще и 
очень хорошо. Кто его знает, что там в новой версии напишут. 

  Кстати, наш php.ini не менялся с 5.2.11. Ревизия и обновление 
php.ini тоже в моем ближайшем TODO. Но хочется сперва 
определиться, будем ли мы делать две ветки или всё-таки одну.

> У меня есть мысль, которую я уже давно думаю..
> отказаться от идеи ведения нескольких версий PHP в 
> репозитории, ибо оно  
> в принципе не так что бы очень актуально. 

  Актуальность -- она субъективная. Мне вот тоже две ветки 
неактуально. Но за две ветки явно высказались mithraen@, 
dubrsl@ и lnkvisitor@.

> При этом можно попробовать  
> сделать один конфиг для PHP, без привязки к версиям, который 
> не будет обновляться при установке новой версии.

  Только давай постараемся не сломать версионированную систему 
legion'а. У меня предчувствие, что она еще понадобится не раз, 
и даже безотносительно php6.

-- 
WBR,
Sergey Kurakin

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Alexey Gladkov]

On 10.08.2010 13:49, Slava Dubrovskiy wrote:
> А расскажите пожалуйста, почему сборка php сделана именно так? 

Изначально в php нет общий библиотеки и все SAPI вкомпиливают в себя
весь интерпретатор. Этот подход прост, но раздувает например mod_php
на 4M.

> 1. Т. е. почему каждый sapi и ext собирается из своего srpm?

Была реализована схема при которой, необходимые модули могли бы
собираться не только мантейнером php, но и другими людьми. Как вы
успели заменить сейчас есть такие модули. Потому что при пересборке
php со всеми модулями мантейнер php не может проверить их
работоспособность, только собираемость и загружаемость (это
необходимое, но не достаточное условие).

> 2. Зачем конфиги располагаются в версийзависимых директориях?

Чтобы можно было держать несколько php разных версий одновременно.

> Обновление php это просто ад. Приходится вручную проверять все изменения
> и вносить их заново.

Если происходит обновление по минорной версии, то достаточно
переместить конфиги.

> 3. Зачем safe-mode включен по умолчанию? 

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

-- 
Rgrds, legion

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Sergey Kurakin]

On 10 August 2010, Alexey Gladkov wrote:
> On 10.08.2010 13:49, Slava Dubrovskiy wrote:

> > Обновление php это просто ад. Приходится вручную проверять 
> > все изменения и вносить их заново.

> Если происходит обновление по минорной версии, то достаточно
> переместить конфиги.

  Что значит "переместить"? Просто скопировать нельзя, там есть 
ссылки на версионированные директории -- extension_dir и пр.

> > 3. Зачем safe-mode включен по умолчанию? 

> Не знаю как сейчас, но раньше я делал для этих целей control.

  Во-во! Я только-что о нем вспоминал по треду немного выше и 
вбок. Сейчас точно так же, control(8) есть и работает. Он и 
должен работать, потому что ни php.ini ни control facilities не 
менялись со времен 5.2.11.

  Только им мало кто пользуется для php. И я почему-то не 
пользовался последние полтора года. А зря.

  Но прежде чем предлагать control, надо бы подтянуть php.ini и 
facilities к уровню 5.2.14. Сейчас глянул мельком, в 5.2.14 
есть некоторое количество новых параметров по сравнению с 
5.2.11. Займусь не спеша, если, конечно, rider@ меня не 
опередит.

  А safe-mode я бы вынес из "restricted" в отдельный 
профиль "safe-mode", оставив по умолчанию "restricted".

> В одном из его профилей все гайки были раскручены. Также был 
> реализован механизм для создания своих профилей для control.

  В каком пакете этот механизм?

-- 
WBR,
Sergey Kurakin

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Alexey Gladkov]

On 10.08.2010 21:21, Sergey Kurakin wrote:
>   Что значит "переместить"? Просто скопировать нельзя, там есть 
> ссылки на версионированные директории -- extension_dir и пр.

Ах да ... Вроде я что-то для этого делал... кажется phpini-migrate.

>   В каком пакете этот механизм?

Там же. Посмотрите:

/etc/php/<version>/cli/control.d/php.example

-- 
Rgrds, legion

Re: [devel] Умолчания PHP [was: PHP 5.3.3]

[Dmitriy Kulik]

2010/8/10 Sergey Kurakin <kurakin@altlinux.ru>:
> On 10 August 2010, Anton Farygin wrote:
>> 10.08.2010 16:20, Slava Dubrovskiy пишет:
>> > Но проблема остается. При каждом обновлении конфиги
>> > приходится проверять
>> > и править вручную. pre и post скрипты не работают.
>>
>> А в этих скриптах и нет ничего такого, что бы могло помочь.
>
>  Как ни странно, нечто такое там есть. В пакете php-base есть
> скрипт phpini-migrate by legion@ (2006).
>
>  Но запускать его из post я бы в любом случае не стал. По этой
> причине и не вчитывался...
>
>  Думаю, что неплохим решением проблемы php.ini мог бы стать
> control(8). Посмотрю, что там и как.
>
>  А вообще, необходимость каждый раз при смене версии
> просматривать php.ini -- это не только очень плохо, но еще и
> очень хорошо. Кто его знает, что там в новой версии напишут.
>
>  Кстати, наш php.ini не менялся с 5.2.11. Ревизия и обновление
> php.ini тоже в моем ближайшем TODO. Но хочется сперва
> определиться, будем ли мы делать две ветки или всё-таки одну.
>
>> У меня есть мысль, которую я уже давно думаю..
>> отказаться от идеи ведения нескольких версий PHP в
>> репозитории, ибо оно
>> в принципе не так что бы очень актуально.
>
>  Актуальность -- она субъективная. Мне вот тоже две ветки
> неактуально. Но за две ветки явно высказались mithraen@,
> dubrsl@ и lnkvisitor@.

Я высказался по поводу хранения конфигураций разных версий. Различий
между 5.2 и 5.3 не делаю в принципе никаких. А вот шестерку хотел бы
видеть в отдельной ветке.

>> При этом можно попробовать
>> сделать один конфиг для PHP, без привязки к версиям, который
>> не будет обновляться при установке новой версии.
>
>  Только давай постараемся не сломать версионированную систему
> legion'а. У меня предчувствие, что она еще понадобится не раз,
> и даже безотносительно php6.
>
> --
> WBR,
> Sergey Kurakin
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Sergey Vlasov]

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

On Tue, Aug 10, 2010 at 07:13:31PM +0400, Alexey Gladkov wrote:
> On 10.08.2010 13:49, Slava Dubrovskiy wrote:
[...]
> > 2. Зачем конфиги располагаются в версийзависимых директориях?
> 
> Чтобы можно было держать несколько php разных версий одновременно.

Вопрос в том, насколько разных?  Т.е., нужно ли обеспечивать
теоретическую возможность наличия рядом, например, 5.2.13 и 5.2.14?

Кстати, использованный метод реализации (php_ini_path_override в
каждом sapi) в некоторых случаях ведёт себя не так, как оригинальный
(например, если установлена переменная PHPRC, но в указанном там
каталоге нет php.ini, системный php.ini не будет найден).  Возможно,
применённая схема была не совсем правильной (вместо засовывания
каждого sapi в отдельный каталог можно было собирать php с
--with-config-file-path=%php5_sysconfdir, а для поддержки отдельных
файлов конфигурации для разных sapi создавать там файлы php-SAPI.ini,
не трогая стандартный механизм поиска).

Впрочем, основная проблема в наличии в php.ini настроек, зависящих от
версии php - safe_mode_include_dir, include_path, extension_dir,
alt_sapi_config_ini_scan_dir, из-за которых при изменении версии php в
любом случае придётся править этот файл.  Причём введение переменной
alt_sapi_config_ini_scan_dir, насколько я понял, вызвано главным
образом желанием использовать отдельные каталоги для разных sapi (в
противном случае хватило бы опять-таки сборки с нужным значением
--with-config-file-scan-dir); в принципе это место можно попытаться
пропатчить для использования php-SAPI.d и избавиться от переменной в
php.ini (которая тоже добавлена патчем).

Ещё можно попробовать перенести в main/main.c инициализацию части
констант (как минимум PHP_VERSION) до вызова php_init_config(); тогда
можно будет писать в php.ini что-то типа

  alt_sapi_config_ini_scan_dir = "/etc/php/" PHP_VERSION "/cli/php.d"

Кстати, в ветке 5.3 это изменение порядка инициализации уже сделано.
Тогда можно будет иметь php.ini с содержимым, не зависящим от версии,
и, например, по умолчанию класть в каталог с конкретным номером версии
симлинк на файл из каталога php-5.2 (или 5.3 - их, видимо, всё-таки
придётся разносить), а уже те файлы просто объявить как %config.
Правда, остаётся открытым вопрос с обновлением фрагментов конфигурации
для расширений.

> > Обновление php это просто ад. Приходится вручную проверять все изменения
> > и вносить их заново.
> 
> Если происходит обновление по минорной версии, то достаточно
> переместить конфиги.

Однако автоматически это не происходит.  Можно допустить, что при
обновлении типа 5.2.x -> 5.3.x что-то действительно нужно менять
вручную, но в пределах одной ветки (как сейчас, 5.2.13 -> 5.2.14)
хотелось бы хоть какой-то автоматизации.

> > 3. Зачем safe-mode включен по умолчанию? 
> 
> Не знаю как сейчас, но раньше я делал для этих целей control. В одном
> из его профилей все гайки были раскручены. Также был реализован
> механизм для создания своих профилей для control.

control там и сейчас есть, но при обновлении пакета опять-таки не
помогает.  Файлы для создания своих профилей кладутся в каталог с
жёсткой зависимостью от номера версии php - т.е., при обновлении
минорной версии эти файлы тоже придётся перекладывать.

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

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Alexey Gladkov]

On 10.08.2010 23:01, Sergey Vlasov wrote:
> Вопрос в том, насколько разных?  Т.е., нужно ли обеспечивать
> теоретическую возможность наличия рядом, например, 5.2.13 и 5.2.14?

На моей памяти был случай когда при обновлении минорной версии было
сломано поведение функций ... кажется это было связано с отправкой почты.

> каждого sapi в отдельный каталог можно было собирать php с
> --with-config-file-path=%php5_sysconfdir,

Разделение по конфигам появилась до этих опций.

> в принципе это место можно попытаться
> пропатчить для использования php-SAPI.d и избавиться от переменной в
> php.ini (которая тоже добавлена патчем).
> 
> Ещё можно попробовать перенести в main/main.c инициализацию части
> констант (как минимум PHP_VERSION) до вызова php_init_config(); тогда
> можно будет писать в php.ini что-то типа
> 
>   alt_sapi_config_ini_scan_dir = "/etc/php/" PHP_VERSION "/cli/php.d"

Новому мантейнеру и карты в руки. Не буду спорить, что мои патчи устарели.

> control там и сейчас есть, но при обновлении пакета опять-таки не
> помогает.  Файлы для создания своих профилей кладутся в каталог с
> жёсткой зависимостью от номера версии php - т.е., при обновлении
> минорной версии эти файлы тоже придётся перекладывать.

Это тоже можно изменить. Хотя мне казалось, что механизм с control для
php не востребован ни в каком виде.

-- 
Rgrds, legion

Re: [devel] Умолчания PHP [was: PHP 5.3.3]

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

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

On Tue, Aug 10, 2010 at 04:37:45PM +0400, Anton Farygin wrote:

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

Ужас-ужас-ужас!

Может просто класть конфиги в каталоги типа 5.2, а не 5.2.14?

И сделать таки возможным существования рядом 5.2/5.3 и т.д.

subminor версии вполне себе переживут с одинаковым конфигом. А вот при
переездах типа 5.2->5.3 все равно конфиг надо глазами смотреть.

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

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

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

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Dmitriy Kulik]

Тема немного иная но тоже относится к пыху и конфигурации.

Почему расширения зенд подключаются как обычные расширения? Так же
возможно использовать их полный функционал. Например тот же xdebug.
Мне кажется это тоже надо как-то фиксить.

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Dmitriy Kulik]

2010/8/11 Dmitriy Kulik <lnkvisitor@altlinux.org>:
> Тема немного иная но тоже относится к пыху и конфигурации.
>
> Почему расширения зенд подключаются как обычные расширения? Так же
> возможно использовать их полный функционал. Например тот же xdebug.
> Мне кажется это тоже надо как-то фиксить.

Извиняюсь. НЕ возможно использовать.

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Anton Farygin]

11.08.2010 13:28, Dmitriy Kulik пишет:
> 2010/8/11 Dmitriy Kulik<lnkvisitor@altlinux.org>:
>> Тема немного иная но тоже относится к пыху и конфигурации.
>>
>> Почему расширения зенд подключаются как обычные расширения? Так же
>> возможно использовать их полный функционал. Например тот же xdebug.
>> Мне кажется это тоже надо как-то фиксить.
>
> Извиняюсь. НЕ возможно использовать.

Патчи приветствуются.

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Dmitriy Kulik]

2010/8/11 Anton Farygin <rider@altlinux.com>:
> 11.08.2010 13:28, Dmitriy Kulik пишет:
>>
>> 2010/8/11 Dmitriy Kulik<lnkvisitor@altlinux.org>:
>>>
>>> Тема немного иная но тоже относится к пыху и конфигурации.
>>>
>>> Почему расширения зенд подключаются как обычные расширения? Так же
>>> возможно использовать их полный функционал. Например тот же xdebug.
>>> Мне кажется это тоже надо как-то фиксить.
>>
>> Извиняюсь. НЕ возможно использовать.
>
> Патчи приветствуются.
Здесь и патчи не требуются
Вместо extension zend_extension
А также полный путь к либе.
Типа так
zend_extension=/usr/lib/php/5.2.11/extensions/xdebug.so
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Anton Farygin]

11.08.2010 14:20, Dmitriy Kulik пишет:
> 2010/8/11 Anton Farygin<rider@altlinux.com>:
>> 11.08.2010 13:28, Dmitriy Kulik пишет:
>>>
>>> 2010/8/11 Dmitriy Kulik<lnkvisitor@altlinux.org>:
>>>>
>>>> Тема немного иная но тоже относится к пыху и конфигурации.
>>>>
>>>> Почему расширения зенд подключаются как обычные расширения? Так же
>>>> возможно использовать их полный функционал. Например тот же xdebug.
>>>> Мне кажется это тоже надо как-то фиксить.
>>>
>>> Извиняюсь. НЕ возможно использовать.
>>
>> Патчи приветствуются.
> Здесь и патчи не требуются
> Вместо extension zend_extension
> А также полный путь к либе.
> Типа так
> zend_extension=/usr/lib/php/5.2.11/extensions/xdebug.so

Патчи требуются ;)

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Dmitriy Kulik]

2010/8/11 Anton Farygin <rider@altlinux.com>:
> 11.08.2010 14:20, Dmitriy Kulik пишет:
>>
>> 2010/8/11 Anton Farygin<rider@altlinux.com>:
>>>
>>> 11.08.2010 13:28, Dmitriy Kulik пишет:
>>>>
>>>> 2010/8/11 Dmitriy Kulik<lnkvisitor@altlinux.org>:
>>>>>
>>>>> Тема немного иная но тоже относится к пыху и конфигурации.
>>>>>
>>>>> Почему расширения зенд подключаются как обычные расширения? Так же
>>>>> возможно использовать их полный функционал. Например тот же xdebug.
>>>>> Мне кажется это тоже надо как-то фиксить.
>>>>
>>>> Извиняюсь. НЕ возможно использовать.
>>>
>>> Патчи приветствуются.
>>
>> Здесь и патчи не требуются
>> Вместо extension zend_extension
>> А также полный путь к либе.
>> Типа так
>> zend_extension=/usr/lib/php/5.2.11/extensions/xdebug.so
>
> Патчи требуются ;)
Боюсь  что после следующего моего сообщения ты скажешь "Собирай сам!!" ;)

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Anton Farygin]

11.08.2010 16:24, Dmitriy Kulik пишет:
> 2010/8/11 Anton Farygin<rider@altlinux.com>:
>> 11.08.2010 14:20, Dmitriy Kulik пишет:
>>>
>>> 2010/8/11 Anton Farygin<rider@altlinux.com>:
>>>>
>>>> 11.08.2010 13:28, Dmitriy Kulik пишет:
>>>>>
>>>>> 2010/8/11 Dmitriy Kulik<lnkvisitor@altlinux.org>:
>>>>>>
>>>>>> Тема немного иная но тоже относится к пыху и конфигурации.
>>>>>>
>>>>>> Почему расширения зенд подключаются как обычные расширения? Так же
>>>>>> возможно использовать их полный функционал. Например тот же xdebug.
>>>>>> Мне кажется это тоже надо как-то фиксить.
>>>>>
>>>>> Извиняюсь. НЕ возможно использовать.
>>>>
>>>> Патчи приветствуются.
>>>
>>> Здесь и патчи не требуются
>>> Вместо extension zend_extension
>>> А также полный путь к либе.
>>> Типа так
>>> zend_extension=/usr/lib/php/5.2.11/extensions/xdebug.so
>>
>> Патчи требуются ;)
> Боюсь  что после следующего моего сообщения ты скажешь "Собирай сам!!" ;)

Нет, не скажу...

выложи в git исправления, я смержусь.

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Dmitriy Kulik]

2010/8/11 Anton Farygin <rider@altlinux.com>:
> 11.08.2010 16:24, Dmitriy Kulik пишет:
>>
>> 2010/8/11 Anton Farygin<rider@altlinux.com>:
>>>
>>> 11.08.2010 14:20, Dmitriy Kulik пишет:
>>>>
>>>> 2010/8/11 Anton Farygin<rider@altlinux.com>:
>>>>>
>>>>> 11.08.2010 13:28, Dmitriy Kulik пишет:
>>>>>>
>>>>>> 2010/8/11 Dmitriy Kulik<lnkvisitor@altlinux.org>:
>>>>>>>
>>>>>>> Тема немного иная но тоже относится к пыху и конфигурации.
>>>>>>>
>>>>>>> Почему расширения зенд подключаются как обычные расширения? Так же
>>>>>>> возможно использовать их полный функционал. Например тот же xdebug.
>>>>>>> Мне кажется это тоже надо как-то фиксить.
>>>>>>
>>>>>> Извиняюсь. НЕ возможно использовать.
>>>>>
>>>>> Патчи приветствуются.
>>>>
>>>> Здесь и патчи не требуются
>>>> Вместо extension zend_extension
>>>> А также полный путь к либе.
>>>> Типа так
>>>> zend_extension=/usr/lib/php/5.2.11/extensions/xdebug.so
>>>
>>> Патчи требуются ;)
>>
>> Боюсь  что после следующего моего сообщения ты скажешь "Собирай сам!!" ;)
>
> Нет, не скажу...
>
> выложи в git исправления, я смержусь.

/people/lnkvisitor/packages/php5-xdebug.git
На счет остальных пока-что не в курсе.
Но тред для этого отдельно есть.

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Slava Dubrovskiy]

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

10.08.2010 22:01, Sergey Vlasov пишет:
>
>>> 2. Зачем конфиги располагаются в версийзависимых директориях?
>>>       
>> Чтобы можно было держать несколько php разных версий одновременно.
>>     
> Вопрос в том, насколько разных?  Т.е., нужно ли обеспечивать
> теоретическую возможность наличия рядом, например, 5.2.13 и 5.2.14?
>   
Я думаю что такой необходимости нет. Например Cpanel предоставляет 2
версии (4 и 5 ветки) одновременно, но выбор внутри ветки ограничен одной
версией. В нашем случае разница между 5.2 и 5.3 достаточно существенна и
есть необходимость иметь возможность иметь их обе в системе.
Поэтому поддерживаю Антона в том, чтобы убрать разделение конфигов по
минорной версии и сделать, например, так:
/etc/php/5.2
/etc/php/5.3
и т.д.
где будут в подпапках с именем sapi располагаться конфиги и директории
для расширений.


> Кстати, использованный метод реализации (php_ini_path_override в
> каждом sapi) в некоторых случаях ведёт себя не так, как оригинальный
> (например, если установлена переменная PHPRC, но в указанном там
> каталоге нет php.ini, системный php.ini не будет найден).  Возможно,
> применённая схема была не совсем правильной (вместо засовывания
> каждого sapi в отдельный каталог можно было собирать php с
> --with-config-file-path=%php5_sysconfdir, а для поддержки отдельных
> файлов конфигурации для разных sapi создавать там файлы php-SAPI.ini,
> не трогая стандартный механизм поиска).
>   
Что-то подобное сделано в сборке remi. И я попытался воспроизвести
применительно к АЛЬТ. См. у меня в php53.git
> Впрочем, основная проблема в наличии в php.ini настроек, зависящих от
> версии php - safe_mode_include_dir, include_path, extension_dir,
> alt_sapi_config_ini_scan_dir, из-за которых при изменении версии php в
> любом случае придётся править этот файл.  Причём введение переменной
> alt_sapi_config_ini_scan_dir, насколько я понял, вызвано главным
> образом желанием использовать отдельные каталоги для разных sapi (в
> противном случае хватило бы опять-таки сборки с нужным значением
> --with-config-file-scan-dir); в принципе это место можно попытаться
> пропатчить для использования php-SAPI.d и избавиться от переменной в
> php.ini (которая тоже добавлена патчем).
>   
Кстати в .ini который идет в оригинале нет никаких переменных. Т.е.
нашли на свою голову проблемы.

>>> Обновление php это просто ад. Приходится вручную проверять все изменения
>>> и вносить их заново.
>>>       
>> Если происходит обновление по минорной версии, то достаточно
>> переместить конфиги.
>>     
> Однако автоматически это не происходит.  Можно допустить, что при
> обновлении типа 5.2.x -> 5.3.x что-то действительно нужно менять
> вручную, но в пределах одной ветки (как сейчас, 5.2.13 -> 5.2.14)
> хотелось бы хоть какой-то автоматизации.
>
>   
+1

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5525 bytes --]

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Slava Dubrovskiy]

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

10.08.2010 18:13, Alexey Gladkov пишет:
> On 10.08.2010 13:49, Slava Dubrovskiy wrote:
>   
>> А расскажите пожалуйста, почему сборка php сделана именно так? 
>>     
> Изначально в php нет общий библиотеки и все SAPI вкомпиливают в себя
> весь интерпретатор. Этот подход прост, но раздувает например mod_php
> на 4M.
>
>   
Ради 4М такой секс.
>> 1. Т. е. почему каждый sapi и ext собирается из своего srpm?
>>     
> Была реализована схема при которой, необходимые модули могли бы
> собираться не только мантейнером php, но и другими людьми. Как вы
> успели заменить сейчас есть такие модули. Потому что при пересборке
> php со всеми модулями мантейнер php не может проверить их
> работоспособность, только собираемость и загружаемость (это
> необходимое, но не достаточное условие).
>
>   
Вроде  для этого существуют внутренние тесты, которые у нас почему-то не
используются.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5525 bytes --]

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Alexey Gladkov]

On 11.08.2010 17:11, Slava Dubrovskiy wrote:
> Ради 4М такой секс.

Я же вас не прошу этим сексом заниматься.

Для меня и эти 4М важны. Зачем влинковывать в бинарник то, что
является библиотекой.

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

Есть не у всех.

-- 
Rgrds, legion

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Dmitriy Kulik]

2010/8/11 Slava Dubrovskiy <slava@tangramltd.com>:
> 10.08.2010 18:13, Alexey Gladkov пишет:
>> On 10.08.2010 13:49, Slava Dubrovskiy wrote:
>>
>>> А расскажите пожалуйста, почему сборка php сделана именно так?
>>>
>> Изначально в php нет общий библиотеки и все SAPI вкомпиливают в себя
>> весь интерпретатор. Этот подход прост, но раздувает например mod_php
>> на 4M.
>>
>>
> Ради 4М такой секс.

А зачем на каждый sapi по 4 метра если можно через shared использовать
либы пыха?
У меня например крутятся оба апача.

>>> 1. Т. е. почему каждый sapi и ext собирается из своего srpm?
>>>
>> Была реализована схема при которой, необходимые модули могли бы
>> собираться не только мантейнером php, но и другими людьми. Как вы
>> успели заменить сейчас есть такие модули. Потому что при пересборке
>> php со всеми модулями мантейнер php не может проверить их
>> работоспособность, только собираемость и загружаемость (это
>> необходимое, но не достаточное условие).
>>
>>
> Вроде  для этого существуют внутренние тесты, которые у нас почему-то не
> используются.
>
> --
> WBR,
> Dubrovskiy Vyacheslav
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Sergey Vlasov]

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

On Wed, Aug 11, 2010 at 03:58:39PM +0300, Slava Dubrovskiy wrote:
> 10.08.2010 22:01, Sergey Vlasov пишет:
> >
> >>> 2. Зачем конфиги располагаются в версийзависимых директориях?
> >>>       
> >> Чтобы можно было держать несколько php разных версий одновременно.
> >>     
> > Вопрос в том, насколько разных?  Т.е., нужно ли обеспечивать
> > теоретическую возможность наличия рядом, например, 5.2.13 и 5.2.14?
> >   
> Я думаю что такой необходимости нет. Например Cpanel предоставляет 2
> версии (4 и 5 ветки) одновременно, но выбор внутри ветки ограничен одной
> версией. В нашем случае разница между 5.2 и 5.3 достаточно существенна и
> есть необходимость иметь возможность иметь их обе в системе.
> Поэтому поддерживаю Антона в том, чтобы убрать разделение конфигов по
> минорной версии и сделать, например, так:
> /etc/php/5.2
> /etc/php/5.3
> и т.д.
> где будут в подпапках с именем sapi располагаться конфиги и директории
> для расширений.

При этом для разноса конфигураций разных sapi по разным каталогам php
надо патчить; в случае размещения всех файлов php-SAPI.ini для одной
версии рядом в одном каталоге даже патчить не надо (кроме scan_dir).

> > Кстати, использованный метод реализации (php_ini_path_override в
> > каждом sapi) в некоторых случаях ведёт себя не так, как оригинальный
> > (например, если установлена переменная PHPRC, но в указанном там
> > каталоге нет php.ini, системный php.ini не будет найден).  Возможно,
> > применённая схема была не совсем правильной (вместо засовывания
> > каждого sapi в отдельный каталог можно было собирать php с
> > --with-config-file-path=%php5_sysconfdir, а для поддержки отдельных
> > файлов конфигурации для разных sapi создавать там файлы php-SAPI.ini,
> > не трогая стандартный механизм поиска).
> >   
> Что-то подобное сделано в сборке remi. И я попытался воспроизвести
> применительно к АЛЬТ. См. у меня в php53.git

Там вариант с дублированием основной части кода (без вынесения
основной части в libphp)?  Тогда поводов для дополнительных патчей ещё
меньше (можно просто конфигурировать каждый вариант sapi с
индивидуальными параметрами).

> > Впрочем, основная проблема в наличии в php.ini настроек, зависящих от
> > версии php - safe_mode_include_dir, include_path, extension_dir,
> > alt_sapi_config_ini_scan_dir, из-за которых при изменении версии php в
> > любом случае придётся править этот файл.  Причём введение переменной
> > alt_sapi_config_ini_scan_dir, насколько я понял, вызвано главным
> > образом желанием использовать отдельные каталоги для разных sapi (в
> > противном случае хватило бы опять-таки сборки с нужным значением
> > --with-config-file-scan-dir); в принципе это место можно попытаться
> > пропатчить для использования php-SAPI.d и избавиться от переменной в
> > php.ini (которая тоже добавлена патчем).
> >   
> Кстати в .ini который идет в оригинале нет никаких переменных. Т.е.
> нашли на свою голову проблемы.

В оригинале там в примерах настроек нет имён каталогов, зависящих от
версии php; в большинстве дистрибутивов, похоже, этим тоже не
заморачиваются.

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

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Slava Dubrovskiy]

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

11.08.2010 21:09, Sergey Vlasov пишет:
> On Wed, Aug 11, 2010 at 03:58:39PM +0300, Slava Dubrovskiy wrote:
>   
>> 10.08.2010 22:01, Sergey Vlasov пишет:
>>     
>>>       
>>>>> 2. Зачем конфиги располагаются в версийзависимых директориях?
>>>>>       
>>>>>           
>>>> Чтобы можно было держать несколько php разных версий одновременно.
>>>>     
>>>>         
>>> Вопрос в том, насколько разных?  Т.е., нужно ли обеспечивать
>>> теоретическую возможность наличия рядом, например, 5.2.13 и 5.2.14?
>>>   
>>>       
>> Я думаю что такой необходимости нет. Например Cpanel предоставляет 2
>> версии (4 и 5 ветки) одновременно, но выбор внутри ветки ограничен одной
>> версией. В нашем случае разница между 5.2 и 5.3 достаточно существенна и
>> есть необходимость иметь возможность иметь их обе в системе.
>> Поэтому поддерживаю Антона в том, чтобы убрать разделение конфигов по
>> минорной версии и сделать, например, так:
>> /etc/php/5.2
>> /etc/php/5.3
>> и т.д.
>> где будут в подпапках с именем sapi располагаться конфиги и директории
>> для расширений.
>>     
> При этом для разноса конфигураций разных sapi по разным каталогам php
> надо патчить; в случае размещения всех файлов php-SAPI.ini для одной
> версии рядом в одном каталоге даже патчить не надо (кроме scan_dir).
>
>   
>>> Кстати, использованный метод реализации (php_ini_path_override в
>>> каждом sapi) в некоторых случаях ведёт себя не так, как оригинальный
>>> (например, если установлена переменная PHPRC, но в указанном там
>>> каталоге нет php.ini, системный php.ini не будет найден).  Возможно,
>>> применённая схема была не совсем правильной (вместо засовывания
>>> каждого sapi в отдельный каталог можно было собирать php с
>>> --with-config-file-path=%php5_sysconfdir, а для поддержки отдельных
>>> файлов конфигурации для разных sapi создавать там файлы php-SAPI.ini,
>>> не трогая стандартный механизм поиска).
>>>   
>>>       
>> Что-то подобное сделано в сборке remi. И я попытался воспроизвести
>> применительно к АЛЬТ. См. у меня в php53.git
>>     
> Там вариант с дублированием основной части кода (без вынесения
> основной части в libphp)?
Да
>   Тогда поводов для дополнительных патчей ещё
> меньше (можно просто конфигурировать каждый вариант sapi с
> индивидуальными параметрами).
>   
Именно так и сделано.

Правда пока я еще не понял все плюсы и минусы выделения libphp.
Вот из плюсов legion@ отметил что mod_php на 4М меньше. Но минус в том,
то нужно патчить все это, получать дополнительные проблемы в виде трудно
обновляемых конфигов.

Но самое важное, это производительность. Мне кажется, что с libphp она
ниже.
Наши девелоперы сделали один достаточно тяжелый магазин. И затем этот же
магазин развернули в соседней VPS.
Получилось 2 VPS с одной версией php но одна на сизифе, вторая на
центосе 5.5. Ничего лишнего там небыло.
И при этом оптимизировали время отдачи контента. Так вот у нас время
отработки скриптов на 10-20% больше чем, например, та же версия php на
центосе собранная без libphp.  Других объяснений, кроме как разного
системы сборки php не могу найти.
Кто-то может объяснить такое?


>>> Впрочем, основная проблема в наличии в php.ini настроек, зависящих от
>>> версии php - safe_mode_include_dir, include_path, extension_dir,
>>> alt_sapi_config_ini_scan_dir, из-за которых при изменении версии php в
>>> любом случае придётся править этот файл.  Причём введение переменной
>>> alt_sapi_config_ini_scan_dir, насколько я понял, вызвано главным
>>> образом желанием использовать отдельные каталоги для разных sapi (в
>>> противном случае хватило бы опять-таки сборки с нужным значением
>>> --with-config-file-scan-dir); в принципе это место можно попытаться
>>> пропатчить для использования php-SAPI.d и избавиться от переменной в
>>> php.ini (которая тоже добавлена патчем).
>>>   
>>>       
>> Кстати в .ini который идет в оригинале нет никаких переменных. Т.е.
>> нашли на свою голову проблемы.
>>     
> В оригинале там в примерах настроек нет имён каталогов, зависящих от
> версии php; в большинстве дистрибутивов, похоже, этим тоже не
> заморачиваются.
>   
Да, именно так.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5525 bytes --]

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Slava Dubrovskiy]

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

11.08.2010 16:48, Alexey Gladkov пишет:
> On 11.08.2010 17:11, Slava Dubrovskiy wrote:
>   
>> Ради 4М такой секс.
>>     
> Я же вас не прошу этим сексом заниматься.
>
> Для меня и эти 4М важны. Зачем влинковывать в бинарник то, что
> является библиотекой.
>   
Пока я вижу такие преимущества влинковки в бинарник:
1. Скорость работы выше.
Например хостинг панели (Cpanel, DirectAdmin) все в бинарник засовывают.

2. Для каждого sapi можно задать свои пути поиска конфигов и директории
поиска конфигов. Что упрощает обновление.

3. Не нужно патчить и изобретать, отрываться от апстрима.

Преимущества наличия libphp:
1. Экономия памяти

Что еще я пропустил?

Кстати, если libphp это действительно библиотека, то почему апстрим её
до сих пор не сделал библиотекой? Кто-то знает? Предлагался ли патч
создания libphp апстриму? Что ответили?

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

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5525 bytes --]

Re: [devel] PHP 5.3.3 [was: Прототипы дизайна интерфейсов Кентавра]

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 653 bytes --]

On Thursday 12 August 2010 00:41, Slava Dubrovskiy wrote:

[...]
> Так вот у нас время
> отработки скриптов на 10-20% больше чем, например, та же версия php на
> центосе собранная без libphp.  Других объяснений, кроме как разного
> системы сборки php не могу найти.
и не только php, а всего, с чем он линкуется

> Кто-то может объяснить такое?
man gcc про -O2
"NOTE: In ALT Linux gcc 4.1.1-alt9 and later versions, -D_FORTIFY_SOURCE=2 is 
set by default, and is activated when -O is set to 2 or higher.  This enables 
additional compile-time and run-time checks for several libc functions"

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[devel] -D_FORTIFY_SOURCE=2

[Alexey Tourbin]

On Thu, Aug 12, 2010 at 02:02:17PM +0400, Sergey V Turchin wrote:
> man gcc про -O2
> "NOTE: In ALT Linux gcc 4.1.1-alt9 and later versions, -D_FORTIFY_SOURCE=2 is 
> set by default, and is activated when -O is set to 2 or higher.

BTW, I find this incomprehensible.  Is it really enabled by default,
or is it only enabled with -O2 and higher?  Leaving aside the fact of
me being curious about whether -Os is higher than -O2...

I felt like fortification and optimization are really different
compiler features.  To me, it's unclear why -O2 should trigger
fortification.

Re: [devel] -D_FORTIFY_SOURCE=2

[Dmitry V. Levin]

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

On Thu, Aug 12, 2010 at 02:19:26PM +0400, Alexey Tourbin wrote:
> On Thu, Aug 12, 2010 at 02:02:17PM +0400, Sergey V Turchin wrote:
> > man gcc про -O2
> > "NOTE: In ALT Linux gcc 4.1.1-alt9 and later versions, -D_FORTIFY_SOURCE=2 is 
> > set by default, and is activated when -O is set to 2 or higher.
> 
> BTW, I find this incomprehensible.  Is it really enabled by default,
> or is it only enabled with -O2 and higher?  Leaving aside the fact of
> me being curious about whether -Os is higher than -O2...
> 
> I felt like fortification and optimization are really different
> compiler features.  To me, it's unclear why -O2 should trigger
> fortification.

Yes, that's odd, but _FORTIFY_SOURCE is implemented in glibc header files
this way.


-- 
ldv

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

[devel] тормоза [was: PHP 5.3.3 Прототипы дизайна интерфейсов Кентавра]

[Ildar Mulyukov]

On 12.08.2010 02:41:02, Slava Dubrovskiy wrote:
> Получилось 2 VPS с одной версией php но одна на сизифе, вторая на
> центосе 5.5. Ничего лишнего там небыло.

Настолько разные системы сравнивать бессмысленно. К примеру, я скажу,  
что на ALT Lotus Domino сильно тормозит. На RH всё летает. Ничего  
лишнего там нет. Даже PHP. Какие прикажете делать выводы?
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar.mulyukov@gmail.com
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] тормоза [was: PHP 5.3.3 Прототипы дизайна интерфейсов Кентавра]

[Anton Farygin]

12.08.2010 14:43, Ildar Mulyukov пишет:
> On 12.08.2010 02:41:02, Slava Dubrovskiy wrote:
>> Получилось 2 VPS с одной версией php но одна на сизифе, вторая на
>> центосе 5.5. Ничего лишнего там небыло.
>
> Настолько разные системы сравнивать бессмысленно. К примеру, я скажу,
> что на ALT Lotus Domino сильно тормозит. На RH всё летает. Ничего
> лишнего там нет. Даже PHP. Какие прикажете делать выводы?

ЦентОС не прав ;)

Конечно, надо смотреть в приближении. а в случае с PHP, завистеть может 
от всего что угодно.

Re: [devel] тормоза [was: PHP 5.3.3 Прототипы дизайна интерфейсов Кентавра]

[Dmitriy Kulik]

2010/8/12 Anton Farygin <rider@altlinux.com>:
> 12.08.2010 14:43, Ildar Mulyukov пишет:
>>
>> On 12.08.2010 02:41:02, Slava Dubrovskiy wrote:
>>>
>>> Получилось 2 VPS с одной версией php но одна на сизифе, вторая на
>>> центосе 5.5. Ничего лишнего там небыло.
>>
>> Настолько разные системы сравнивать бессмысленно. К примеру, я скажу,
>> что на ALT Lotus Domino сильно тормозит. На RH всё летает. Ничего
>> лишнего там нет. Даже PHP. Какие прикажете делать выводы?
>
> ЦентОС не прав ;)
>
> Конечно, надо смотреть в приближении. а в случае с PHP, завистеть может от
> всего что угодно.
Это все kernel mode. ;)

Re: [devel] Прототипы дизайна интерфейсов Кентавра

[Alexey Shabalin]

29 июля 2010 г. 16:18 пользователь Андрей Черепанов написал:
> Выложены прототипы дизайна интерфейсов следующей версии дистрибутива ALT Linux
> с кодовым именем Кентавр:
>
> http://www.altlinux.org/ALTLinux_6.0_Centaurus#Screenshots
>
> Дизайн кентавра обсуждаем! поэтому не говорите, что никто не прислушивается к
> мнению сообщества по такой животрепещущей теме, как дизайн дистрибутива!
>
А можно уточнить, чем будут реализованы все эти bootsplash и т.д.
Есть ли в планах использование plymouth (или что сейчас используют
ведущие дистрибутиво-строители)
Если не ошибаюсь с plymouth можно без моргания переходить от консоли
загрузки к gdm.
Для сервера конечно всё равно, но если планируется "конструктор", то
для десктопа хочется "красоты" :)

-- 
Alexey Shabalin

Re: [devel] Прототипы дизайна интерфейсов Кентавра

[Sergey Shilov]

В сообщении от Четверг 12 августа 2010 17:33:03 автор Alexey Shabalin написал:
> 29 июля 2010 г. 16:18 пользователь Андрей Черепанов написал:
> > Выложены прототипы дизайна интерфейсов следующей версии дистрибутива ALT
> > Linux с кодовым именем Кентавр:
> > 
> > http://www.altlinux.org/ALTLinux_6.0_Centaurus#Screenshots
> > 
> > Дизайн кентавра обсуждаем! поэтому не говорите, что никто не
> > прислушивается к мнению сообщества по такой животрепещущей теме, как
> > дизайн дистрибутива!
Вариант1 + логотипы от Вариант2. 
 
> А можно уточнить, чем будут реализованы все эти bootsplash и т.д.
> Есть ли в планах использование plymouth (или что сейчас используют
> ведущие дистрибутиво-строители)
> Если не ошибаюсь с plymouth можно без моргания переходить от консоли
> загрузки к gdm.
> Для сервера конечно всё равно, но если планируется "конструктор", то
> для десктопа хочется "красоты" :)
+ А будет ли эту красоту (Экран загрузки) когда-нибудь видно в "родном" 
разрешении ноутбуко-нетбучных матриц 1280х800 1024х600?
Если раньше Сплэш имел место быть в 800х600 и 1024х768 (при мутной консоли), 
то сейчас (на  2.6.32) его (Сплэша) уже нет.

 
---
V.B.R
S.Shilov

Re: [devel] Умолчания PHP [was: PHP 5.3.3]

[Michael Shigorin]

On Wed, Aug 11, 2010 at 01:19:21PM +0400, Денис Смирнов wrote:
> Может просто класть конфиги в каталоги типа 5.2, а не 5.2.14?
> И сделать таки возможным существования рядом 5.2/5.3 и т.д.
> subminor версии вполне себе переживут с одинаковым конфигом.
> А вот при переездах типа 5.2->5.3 все равно конфиг надо глазами
> смотреть.

(дочитывая devel@, кроме треда про диких гиров) Умгумс.

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