[Comm] дизайн дистрибутива ALJ "как в вындовс"

[Comm] дизайн дистрибутива ALJ "как в вындовс"

[@ 2003-04-28 7:04 UTC (permalink / raw)]

Re: [Comm] дизайн дистрибутива ALJ "как в вындовс"

[@ 2003-04-28 7:27 UTC (permalink / raw)]

Re: [Comm] дизайн дистрибутива ALJ "как в вындовс"

[@ 2003-04-28 8:05 UTC (permalink / raw)]

Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[@ 2003-04-28 8:51 UTC (permalink / raw)]

[Comm] Re: дизайн дистрибутива ALJ "как в вындовс"

[@ 2003-04-28 9:28 UTC (permalink / raw)]

Re: [Comm] ""

[@ 2003-04-28 15:33 UTC (permalink / raw)]

[Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[@ 2003-04-28 16:37 UTC (permalink / raw)]

Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[@ 2003-04-28 17:02 UTC (permalink / raw)]

Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Vitaly Lugovsky]

On Mon, 28 Apr 2003, Roman Bogorodskiy wrote:

> >  А я вот вообще убеждён, что нет смысла в линукс-сообщество
> > переманивать виндовых пользователей. Порченные они все.
> > Нужны НОВЫЕ пользователи, свежие, без дурных привычек.
>
> Имхо большинство линуксойдов - бывшие пользователи Windows.

 Не уверен. Статистика есть где либо достаточно достоверная?

Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Mike Lykov]

В сообщении от 29 Апрель 2003 17:58 Vitaly Lugovsky написал:

> > > Нужны НОВЫЕ пользователи, свежие, без дурных привычек.
> > Имхо большинство линуксойдов - бывшие пользователи Windows.
>  Не уверен. Статистика есть где либо достаточно достоверная?

А откуда ж им еще взяться?
сколько процентов компьютеров в стране занято каким-либо линуксом (не на 
сервере, а на рабочем месте)?

-- 
Mike

Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Andrey Golovin]

На 2003.04.30 09:09 Mike Lykov написал:
> В сообщении от 29 Апрель 2003 17:58 Vitaly Lugovsky
> написал:
> 
> > > > Нужны НОВЫЕ пользователи, свежие,
> без дурных привычек.
> > > Имхо большинство линуксойдов -
> бывшие пользователи Windows.
> >  Не уверен. Статистика есть где либо
> достаточно достоверная?
> 
> А откуда ж им еще взяться?
> сколько процентов компьютеров в
> стране занято каким-либо линуксом (не
> на
> сервере, а на рабочем месте)?

Протестую! Да я перешел на Линукс из 
Винды. НО! Сделал я это потому, что 
после полуоси винда меня совершенно не 
устраивала. А как пользователь я 
воспитывался вообще на RT-11 (хотя первой 
ОС с которой столкнулся была ДЕМОС - 
советский Юникс).
Если кто назовет меня виндусятником - 
получит в глаз.

Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Vitaly Lugovsky]

On Wed, 30 Apr 2003, Mike Lykov wrote:

> > > > Нужны НОВЫЕ пользователи, свежие, без дурных привычек.
> > > Имхо большинство линуксойдов - бывшие пользователи Windows.
> >  Не уверен. Статистика есть где либо достаточно достоверная?
>
> А откуда ж им еще взяться?

 Новые пользователи - ведь их число постоянно растёт, с каждым
годом удваивается, старые пользователи, кто виндовса и не видел и
видеть не хотел (вроде меня).

> сколько процентов компьютеров в стране занято каким-либо
> линуксом (не на
> сервере, а на рабочем месте)?

 Компьютер... На рабочем месте... Идиотизм это.

[Comm] Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Maksim Otstavnov]

Hello Vitaly,

Monday, April 28, 2003, 8:37:53 PM, you wrote:

VL> On Mon, 28 Apr 2003, Mike Lykov wrote:

>> Один человек попробовал описать трудности, которые возникнут у
>> "обычного виндового пользователя" после того, как он установит ALJ
>> и попробует работать.

VL>  А я вот вообще убеждён, что нет смысла в линукс-сообщество
VL> переманивать виндовых пользователей. Порченные они все.

Ну зачем же так зло?

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

Есть те, кто вполне осознанно ищет более эффективных способов работы,
более широкого спектра программ и т.п. Им нужен коррекционный учебный
курс, причем не про конкретный софт, а про общие понятия: что такое
файл, что такое каталог, что такое процесс, что такое программа, что
такое команда и т.п. 90% "вопросов" (про ""приложения" в "папках"")
это снимет, а заодно отфильтрует балласт.

А заманивать вообще никого не нужно никуда IMHO.

-- 
-- M

[Comm] Re[2]: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Maksim Otstavnov]

PS: Я бы еще заметил в этой связи, что, по моим наблюдениям (в
основном, относящимся к корпоративной среде) самая частая точка
миграции "виндузятников" --- когда единственной альтернативой остается
переход от MS-DOS к NT...

Monday, April 28, 2003, 10:05:41 PM, Maksim wrote:

MO> Есть те, кто вполне осознанно ищет более эффективных способов работы,
MO> более широкого спектра программ и т.п. Им нужен коррекционный учебный
MO> курс, причем не про конкретный софт, а про общие понятия: что такое
MO> файл, что такое каталог, что такое процесс, что такое программа, что
MO> такое команда и т.п. 90% "вопросов" (про ""приложения" в "папках"")
MO> это снимет, а заодно отфильтрует балласт.

-- 
-- Maksim

Re: [Comm] Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Vitaly Lugovsky]

On Mon, 28 Apr 2003, Maksim Otstavnov wrote:

> VL>  А я вот вообще убеждён, что нет смысла в линукс-сообщество
> VL> переманивать виндовых пользователей. Порченные они все.
>
> Ну зачем же так зло?
>
> Есть "виндовые пользователи", которые хотят, "как в винде"
> (только
> "чтоб не падало", "чтоб не висло", "чтоб вирусы не ели"...).
> Им стоит мягко объяснять, что так не бывает.

 Даже в этом списке рассылки легко можно видеть, во что подобные
объяснения выливаются... :(

> Есть те, кто вполне осознанно ищет более эффективных способов
> работы,
> более широкого спектра программ и т.п.

 А это не виндовые пользователи. Это "просто пользователи".

> Им нужен коррекционный учебный курс, причем не про конкретный
> софт, а про общие понятия: что такое файл, что такое каталог,
> что такое процесс, что такое программа, что такое команда и
> т.п. 90% "вопросов" (про ""приложения" в "папках"") это снимет,
> а заодно отфильтрует балласт.

 Нужен русский HowTo по Unix Way... Пока такого нет.

> А заманивать вообще никого не нужно никуда IMHO.

 Вот и я о том же.

Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Anton V. Boyarshinov]

On Tue, 29 Apr 2003 17:01:26 +0400 (MSD) Vitaly Lugovsky
 wrote:

> Нужен русский HowTo по Unix Way... Пока такого нет.

Может в docs@ перейдём? В принципе, такая задача поставлена, но
пока не реализована. Уже есть кое-какие обрывочные тексты, но
требуется связующее звено. Возьмётесь?

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 17:12:00  up 54 days, 23:39, 11 users,  load average: 0.08,
0.04, 0.01

[Comm] Re[2]: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Maksim Otstavnov]

Hello Anton,

Tuesday, April 29, 2003, 5:15:42 PM, you wrote:

AVB> On Tue, 29 Apr 2003 17:01:26 +0400 (MSD) Vitaly Lugovsky
AVB>  wrote:

>> Нужен русский HowTo по Unix Way... Пока такого нет.

AVB> Может в docs@ перейдём? В принципе, такая задача поставлена, но
AVB> пока не реализована. Уже есть кое-какие обрывочные тексты, но
AVB> требуется связующее звено. Возьмётесь?

Еще Вагнера надо позвать.

Называется "подготовка документации методом Луговского--Вагнера" :)

-- 
-- Maksim

Re: [Comm] Re[2]: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Vitaly Lugovsky]

On Tue, 29 Apr 2003, Maksim Otstavnov wrote:

> >> Нужен русский HowTo по Unix Way... Пока такого нет.
>
> AVB> Может в docs@ перейдём? В принципе, такая задача поставлена, но
> AVB> пока не реализована. Уже есть кое-какие обрывочные тексты, но
> AVB> требуется связующее звено. Возьмётесь?
>
> Еще Вагнера надо позвать.
>
> Называется "подготовка документации методом
> Луговского--Вагнера" :)

 Это можно. Я даже писать начал помалу, после недавних разборок в
RU.GNU. Пока такие вот критерии выходят:


 * Любое приложение может быть использовано как человеком, так и
   другой программой.
 * Plain text --- достаточно оптимальное и компромиссное
 представление практически любой информации. Приложения должны
 общаться как с пользователем, так и между собой на
 человеко--читабельном языке.
 * Потоки plain text --- достаточно хорошее средство коммуникации
   между компонентами. Их преимущества --- сетевая прозрачность,
   наличие огромного количества готовых средств для обработки,
   возможность встроить эти средства между двумя компонентами.
 * Любое действие, не требующее приложения исключительно
 человеческого интеллекта, должно автоматизироваться.


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

[Comm] Re[2]: [Comm] Re[2]: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Maksim Otstavnov]

Hello Vitaly,

Много хороших формулировок есть в новой книжке Рэймонда
(http://www.catb.org/~esr/writings/taoup/html/). Хотя и выдумок там
тоже есть :)

Tuesday, April 29, 2003, 10:26:36 PM, you wrote:


VL>  Это можно. Я даже писать начал помалу, после недавних разборок в
VL> RU.GNU.

-- 
-- Maksim

Re: Re[2]: [Comm] Re[2]: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Anton V. Boyarshinov]

On Wed, 30 Apr 2003 00:47:03 +0400 Maksim Otstavnov
 wrote:

> Hello Vitaly,
> 
> Много хороших формулировок есть в новой книжке Рэймонда
> (http://www.catb.org/~esr/writings/taoup/html/). Хотя и выдумок
> там тоже есть :)

Я, кстати, затеял пропихивание unix-way в документацию именно под
впечатление от прочтения этой книги ;)


Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 10:20:00  up 55 days, 16:47, 11 users,  load average: 0.77,
0.57, 0.29

Re: Re[2]: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Anton V. Boyarshinov]

On Tue, 29 Apr 2003 17:53:18 +0400 Maksim Otstavnov
 wrote:

> >> Нужен русский HowTo по Unix Way... Пока такого нет.
> 
> AVB> Может в docs@ перейдём? В принципе, такая задача
> AVB> поставлена, но пока не реализована. Уже есть кое-какие
> AVB> обрывочные тексты, но требуется связующее звено.
> AVB> Возьмётесь?
> 
> Еще Вагнера надо позвать.

Надо. Только как его в docs@a.r заманить? ;)

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 10:20:00  up 55 days, 16:47, 11 users,  load average: 0.77,
0.57, 0.29

[Comm] Re: дизайн дистрибутива ALJ "как в вындовс"

[Alexey Tourbin]

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

On Mon, Apr 28, 2003 at 10:05:41PM +0400, Maksim Otstavnov wrote:
> Есть те, кто вполне осознанно ищет более эффективных способов работы,
> более широкого спектра программ и т.п. Им нужен коррекционный учебный
> курс, причем не про конкретный софт, а про общие понятия: что такое
> файл, что такое каталог, что такое процесс, что такое программа, что
> такое команда и т.п. 90% "вопросов" (про ""приложения" в "папках"")
> это снимет, а заодно отфильтрует балласт.

К сожалению, документация ALJ2.2 в этом отношении практически не
содержит полезной информации для начинающих.  В разделе "Что такое
Linux" даже не написано, что Linux -- это UNIX-подобная система (хотя
упоминаются BSD).  Зато очень много идеологии и рекламы.  Два чувства
дивно близки нам.  Тоже мне. 

Помню, что в ALM2.0 был раздел, который назывался "Основы работы в
shell" или как-то так.  В ALM2.2 этого раздела уже нет.

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

Re: [Comm] Re: [Comm] [JT] дизайн дис трибутива ALJ "как в в ындовс"

[Denis Smirnov]

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

On Mon, Apr 28, 2003 at 08:37:53PM +0400, Vitaly Lugovsky wrote:

 >  А я вот вообще убеждён, что нет смысла в линукс-сообщество
 > переманивать виндовых пользователей. Порченные они все.
 > Нужны НОВЫЕ пользователи, свежие, без дурных привычек.

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

 >>  1.3. Операции с файлами и папками, дисками (форматирование,
 >> проверка и пр.)
 >  Пользователю ЭТО надо?!?

А как пользователю обойтись без форматирования сменных носителей? 
 
 >>  2.1. Работа с текстовыми документами
 >>  2.2. Работа с электронными таблицами
 >  От прям таки усем это надо?!?

Я уже давно думаю и пытаюсь найти кошерный аналог ёкселя. Не получается.
Каждый раз, когда нужна какая-то одноразовая задача, которая вписывается в
идеологию электронных таблиц -- ничего лучше ёкселя не придумал :(
 
-- 
С уважением, Денис

http://freesource.info

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

Re: [Comm] Re: [Comm] [JT] дизайн дис трибутива ALJ "как в в ындовс"

[Vitaly Lugovsky]

On Mon, 28 Apr 2003, Denis Smirnov wrote:

>  >  А я вот вообще убеждён, что нет смысла в линукс-сообщество
>  > переманивать виндовых пользователей. Порченные они все.
>  > Нужны НОВЫЕ пользователи, свежие, без дурных привычек.
>
> Нужны те пользователи, которые хотят и умеют думать головой.
> Независимо от
> того, какая была их прошлая среда обитания :)

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

>  >>  1.3. Операции с файлами и папками, дисками (форматирование,
>  >> проверка и пр.)
>  >  Пользователю ЭТО надо?!?
>
> А как пользователю обойтись без форматирования сменных
> носителей?

 Я даже на сидюки tar пишу.

>  >>  2.1. Работа с текстовыми документами
>  >>  2.2. Работа с электронными таблицами
>  >  От прям таки усем это надо?!?
>
> Я уже давно думаю и пытаюсь найти кошерный аналог ёкселя. Не
> получается.
> Каждый раз, когда нужна какая-то одноразовая задача, которая
> вписывается в
> идеологию электронных таблиц -- ничего лучше ёкселя не
> придумал :(

 Я знаю, что такие задачи есть. Бывают иногда. У меня вот - ни
разу не было. Сомневаюсь лишь в том, что они настолько частые и
нужные, что входят в требования среднестатического юзера.

Re: [Comm] Re: [Comm] [JT]

[Denis Smirnov]

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

On Tue, Apr 29, 2003 at 05:05:06PM +0400, Vitaly Lugovsky wrote:

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

Собственно их переманивание == создание средств и документации, которые им
необходиы.
 
 >>>>  1.3. Операции с файлами и папками, дисками (форматирование,
 >>>> проверка и пр.)
 >>>  Пользователю ЭТО надо?!?
 >> А как пользователю обойтись без форматирования сменных
 >> носителей?
 >  Я даже на сидюки tar пишу.

Маньяк :)

Вся жопа в том, что люди _уже_ привыкли к использованию кривых подходов
при работе. И поэтому нужна чёткая и понятная документация по более
правильным подходам, с чётким логичным объяснением почему они правильны и
как ими пользоваться.
 
-- 
С уважением, Денис

http://freesource.info

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

Re: [Comm] Re: [Comm] [JT]

[Mike Lykov]

В сообщении от 29 Апрель 2003 23:11 Denis Smirnov написал:

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

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

-- 
Mike

[Comm] Re: дизайн дис трибутива ALJ "как в в ындовс"

[Alexey Tourbin]

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

On Mon, Apr 28, 2003 at 11:25:49PM +0400, Denis Smirnov wrote:
> On Mon, Apr 28, 2003 at 08:37:53PM +0400, Vitaly Lugovsky wrote:
> 
>  >  А я вот вообще убеждён, что нет смысла в линукс-сообщество
>  > переманивать виндовых пользователей. Порченные они все.
>  > Нужны НОВЫЕ пользователи, свежие, без дурных привычек.
> 
> Нужны те пользователи, которые хотят и умеют думать головой. Независимо от
> того, какая была их прошлая среда обитания :)
> 
>  >>  1.3. Операции с файлами и папками, дисками (форматирование,
>  >> проверка и пр.)
>  >  Пользователю ЭТО надо?!?
> 
> А как пользователю обойтись без форматирования сменных носителей? 

И (особенно) без дефрагментации диска.  По моим ощущением, последнее
суть очень частое занятие, которое доставляет много удовольствия
"пользователям, которые хотят и умеют думать головой". :)

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

Re: [Comm] Re:

[Denis Smirnov]

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

On Tue, May 06, 2003 at 05:24:29PM +0400, Alexey Tourbin wrote:

> И (особенно) без дефрагментации диска.  По моим ощущением, последнее
> суть очень частое занятие, которое доставляет много удовольствия
> "пользователям, которые хотят и умеют думать головой". :)

Зачем под линуксом может быть нужна дефрагментация -- не представляю :)

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

http://freesource.info

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

[Comm] Re:

[Michael Shigorin]

On Tue, May 06, 2003 at 05:49:41PM +0400, Denis Smirnov wrote:
> > И (особенно) без дефрагментации диска.  По моим ощущением, последнее
> > суть очень частое занятие, которое доставляет много удовольствия
> > "пользователям, которые хотят и умеют думать головой". :)

Ну, это-то понятно -- вешается не менее красивая фенечка-демка .)

> Зачем под линуксом может быть нужна дефрагментация -- не представляю :)

Есть еще такая штука, как оптимизация сиков по типичному процессу
загрузки.  Не знаю, правда, как это вообще можно реализовать в
сколь-нибудь нетривиальном случае с отдельным /usr (не говоря о
нескольких дисках).

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

Re: [Comm] Re:

[Denis Smirnov]

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

On Wed, May 07, 2003 at 02:30:37PM +0300, Michael Shigorin wrote:

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

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

http://freesource.info

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

[Comm] Re:

[Michael Shigorin]

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

On Wed, May 07, 2003 at 04:33:12PM +0400, Denis Smirnov wrote:
>  > Есть еще такая штука, как оптимизация сиков по типичному процессу
>  > загрузки.  Не знаю, правда, как это вообще можно реализовать в
>  > сколь-нибудь нетривиальном случае с отдельным /usr (не говоря о
>  > нескольких дисках).
> Изменение структуры загрузки так, чтобы могло запускаться одновременно
> несколько процессов инициализации, ускорит загрузку гораздо заметнее.

Если есть прикладные соображения -- лучше в devel@.

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

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

Re: [Comm] Re:

[Denis Smirnov]

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

On Thu, May 08, 2003 at 11:29:48AM +0300, Michael Shigorin wrote:

 >>> Есть еще такая штука, как оптимизация сиков по типичному процессу
 >>> загрузки.  Не знаю, правда, как это вообще можно реализовать в
 >>> сколь-нибудь нетривиальном случае с отдельным /usr (не говоря о
 >>> нескольких дисках).
 >> Изменение структуры загрузки так, чтобы могло запускаться одновременно
 >> несколько процессов инициализации, ускорит загрузку гораздо заметнее.
 > Если есть прикладные соображения -- лучше в devel@.

У меня были только общие идеи. Для каждого стартового скрипта должно быть
описание зависимостей -- после запуска какого скрипта можно запускать этот
скрипт. Зависимость должна быть двух типов -- обязательная, и
необязательная. Обязательная -- значит что если не поднимается тот сервис,
от которого зависит нужный нам, то он даже не будет пытаться подниматься.
Необязательные -- только обеспечивают соблюдение очерёдности.

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

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

http://freesource.info


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

Re[2]: [Comm] Re:

[ASA]

Hello Denis,

Friday, May 9, 2003, 12:13:58 AM, you wrote:

DS>  >> Изменение структуры загрузки так, чтобы могло запускаться одновременно
DS>  >> несколько процессов инициализации, ускорит загрузку гораздо заметнее.

DS> У меня были только общие идеи. Для каждого стартового скрипта должно быть
DS> описание зависимостей -- после запуска какого скрипта можно запускать этот
DS> скрипт. Зависимость должна быть двух типов -- обязательная, и
DS> необязательная. Обязательная -- значит что если не поднимается тот сервис,
DS> от которого зависит нужный нам, то он даже не будет пытаться подниматься.
Вы только что описали систему поднятия сервисов в WinNT/2000/XP ;)

DS> Необязательные -- только обеспечивают соблюдение очерёдности.
А  это  хорошая  идея.  Относительно.  Но очередность уже есть в
SysV.

DS> Думаю доказывать прирост в скорости загрузки не надо.
Надо.   С   теми  скриптами,  которые  в  основном  налегают  на
недисковые  ресурсы (сеть, обработка конфигов и т.п.) - понятно.
А  если скрипт в основном завязан на диск, то его надо запускать
отдельно   от  других  подобных  ему.  И  тут  может  возникнуть
нетривиальная  задача  развязки  обязательных  и  необязательных
зависимостей.

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

В  сам  S-скрипт (те, которые лежат в init.d) добавляем еще одно
поле  типа  как это сделано для chkconfig. В этом поле указываем
класс скрипта - дисковый или нет.

Затем    rc-скрипт   (тот,   который   обеспечивает   выполнение
SysV-инициализации)  последовательно выполняет скрипты не просто
отсортировав SXX по порядку (типа `echo S*|sort`), а разбивая их
на  группы  по  приоритету  (S00  -  в одну кучу, S01 в другую и
т.п.).  Внутри  этой  группы  rc смотрит на поле класса скрипта,
находит  и  запускает  в  два  независимых "потока" "дисковые" и
"недисковые" скрипты.

Получаем,  во-первых,  полную  совместимость  с уже существующим
софтом,    завязанным    на   SysV,   а   во-вторых,   требуемое
распараллеливание скриптов.

Можно  пойти  дальше  и  ввести  еще  одно  поле  в  S-скрипте -
зависимость  от  уже  стартовавшего  сервиса.  Реализация именно
такого  способа  задания  зависимостей  не  представляет  вообще
никакого труда.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re:

[Denis Smirnov]

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

On Fri, May 09, 2003 at 03:06:42AM +0500, ASA wrote:

> DS> У меня были только общие идеи. Для каждого стартового скрипта должно быть
> DS> описание зависимостей -- после запуска какого скрипта можно запускать этот
> DS> скрипт. Зависимость должна быть двух типов -- обязательная, и
> DS> необязательная. Обязательная -- значит что если не поднимается тот сервис,
> DS> от которого зависит нужный нам, то он даже не будет пытаться подниматься.
> Вы только что описали систему поднятия сервисов в WinNT/2000/XP ;)

:)

> DS> Необязательные -- только обеспечивают соблюдение очерёдности.
> А  это  хорошая  идея.  Относительно.  Но очередность уже есть в
> SysV.

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

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

 > DS> Думаю доказывать прирост в скорости загрузки не надо.
 > Надо.   С   теми  скриптами,  которые  в  основном  налегают  на
 > недисковые  ресурсы (сеть, обработка конфигов и т.п.) - понятно.
 > А  если скрипт в основном завязан на диск, то его надо запускать
 > отдельно   от  других  подобных  ему.  И  тут  может  возникнуть
 > нетривиальная  задача  развязки  обязательных  и  необязательных
 > зависимостей.

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

Насчёт завязки на диск -- что это, например? Сервер БД на что больше
завязан? IMHO сервер БД можно запускать как только смонтированы все
разделы и подняты интерфейсы (если он не локальный).

Для многопроцессорных систем польза от многопоточного запуска, IMHO,
очевидна. 

Ещё можно вспонмить известный факт с многопроцессной компиляцией (make
-jN), которая увеличивает скорость компиляции даже на однопроцессорных
машинах.

 > DS> Вопрос только в
 > DS> одном -- настолько ли оно надо, чтобы тратить на это силы?
 > Имхо нет. Предлагаю промежуточную копромиссную схему, которая не
 > требует больших усилий.
 > В  сам  S-скрипт (те, которые лежат в init.d) добавляем еще одно
 > поле  типа  как это сделано для chkconfig. В этом поле указываем
 > класс скрипта - дисковый или нет.

Тоже вариант. Только вот с классом скрипта непонятно -- как их делить?
Какой у Bind'а? А если он обслуживают тучу зон? А у иксов?
 
 > Затем    rc-скрипт   (тот,   который   обеспечивает   выполнение
 > SysV-инициализации)  последовательно выполняет скрипты не просто
 > отсортировав SXX по порядку (типа `echo S*|sort`), а разбивая их
 > на  группы  по  приоритету  (S00  -  в одну кучу, S01 в другую и
 > т.п.).  Внутри  этой  группы  rc смотрит на поле класса скрипта,
 > находит  и  запускает  в  два  независимых "потока" "дисковые" и
 > "недисковые" скрипты.
 > Получаем,  во-первых,  полную  совместимость  с уже существующим
 > софтом,    завязанным    на   SysV,   а   во-вторых,   требуемое
 > распараллеливание скриптов.
 > Можно  пойти  дальше  и  ввести  еще  одно  поле  в  S-скрипте -
 > зависимость  от  уже  стартовавшего  сервиса.  Реализация именно
 > такого  способа  задания  зависимостей  не  представляет  вообще
 > никакого труда.

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

http://freesource.info

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

Re[2]: [Comm] Re:

[ASA]

Hello Denis,

Friday, May 9, 2003, 4:12:57 AM, you wrote:

>> Вы только что описали систему поднятия сервисов в WinNT/2000/XP ;)
DS> :)

>> DS> Необязательные -- только обеспечивают соблюдение очерёдности.
>> А  это  хорошая  идея.  Относительно.  Но очередность уже есть в
>> SysV.

DS> В SyV она тольно последовательная. Я имею в виду что-то вроде "почтовый
DS> сервер должен запускать после антивирусного сервиса, если таковой
DS> имеется".
Как мы отметили ниже, такое можно реализовать без потери
совместимости с SysV.

DS> Соответственно последовательность работы загрузчика следующая -- берётся
DS> список поднимаемый сервисов, строится дерево зависимостей, дальше
DS> запускаем скрипты инициализации для N сервисов, из тех, которые можно
DS> инициализировать сразу. После завершения каждого из скриптов смотрим что
DS> следующее можно инициализировать.

Я  протестую  против  "все  враз".  Если запустить слишком много
программ, то они в сумме отработают медленее, чем в сумме каждая
по    отдельности,    из-за    слишком    большого    количества
разноупорядоченных  обращений  к  диску  (что-то типа hard drive
seek  test  ;). Пример - в той же вынде выделите побольше иконок
на  рабочем  столе  и  нажмите  Enter  ;)  Поэтому  можно ввести
ограничение на одновременную работу не более 4*CPU скриптов враз.

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

DS> А в чём собственно её нетривиальность? Автор пакета должен суметь чётко
DS> сформулировать что необходимо его сервису для работы.

Нетривиальность вообще в создании такого дерева.

DS> Насчёт завязки на диск -- что это, например? Сервер БД на что больше
DS> завязан? IMHO сервер БД можно запускать как только смонтированы все
DS> разделы и подняты интерфейсы (если он не локальный).
то же самое можно сказать про большиснтво других сервисов.
Итак, fsck :), squid, smb
А в целом, да, ты прав, нужно какое-то другое деление.

DS> Для многопроцессорных систем польза от многопоточного запуска, IMHO,
DS> очевидна. 
Но не для hdd.

DS> Ещё можно вспонмить известный факт с многопроцессной компиляцией (make
DS> -jN), которая увеличивает скорость компиляции даже на однопроцессорных
DS> машинах.
Потому  что  тут  постоянно  запускаются  одни и те же программы
(gcc, make, ...), которые уже лежат в кэше.

DS>  > В  сам  S-скрипт (те, которые лежат в init.d) добавляем еще одно
DS>  > поле  типа  как это сделано для chkconfig. В этом поле указываем
DS>  > класс скрипта - дисковый или нет.

DS> Тоже вариант. Только вот с классом скрипта непонятно -- как их делить?
DS> Какой у Bind'а? А если он обслуживают тучу зон? А у иксов?
Думать надо...

DS>  > Можно  пойти  дальше  и  ввести  еще  одно  поле  в  S-скрипте -
DS>  > зависимость  от  уже  стартовавшего  сервиса.  Реализация именно
DS>  > такого  способа  задания  зависимостей  не  представляет  вообще
DS>  > никакого труда.

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

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re:

[Denis Smirnov]

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

On Fri, May 09, 2003 at 11:39:59AM +0500, ASA wrote:

 > DS> В SyV она тольно последовательная. Я имею в виду что-то вроде "почтовый
 > DS> сервер должен запускать после антивирусного сервиса, если таковой
 > DS> имеется".
 > Как мы отметили ниже, такое можно реализовать без потери
 > совместимости с SysV.
 
В какой момент должен запускаться скрипт, если для него ничего не указано?
Считать его зависимых от всех предыдущих по номеру?
 
 > DS> Соответственно последовательность работы загрузчика следующая -- берётся
 > DS> список поднимаемый сервисов, строится дерево зависимостей, дальше
 > DS> запускаем скрипты инициализации для N сервисов, из тех, которые можно
 > DS> инициализировать сразу. После завершения каждого из скриптов смотрим что
 > DS> следующее можно инициализировать.
 > Я  протестую  против  "все  враз".  Если запустить слишком много
 > программ, то они в сумме отработают медленее, чем в сумме каждая
 > по    отдельности,    из-за    слишком    большого    количества
 > разноупорядоченных  обращений  к  диску  (что-то типа hard drive
 > seek  test  ;). Пример - в той же вынде выделите побольше иконок
 > на  рабочем  столе  и  нажмите  Enter  ;)  Поэтому  можно ввести
 > ограничение на одновременную работу не более 4*CPU скриптов враз.

Это конфигурируемо должно быть. По-умолчанию 4*CPU -- оптимум.
 
 > DS>  > отдельно   от  других  подобных  ему.  И  тут  может  возникнуть
 > DS>  > нетривиальная  задача  развязки  обязательных  и  необязательных
 > DS>  > зависимостей.
 > DS> А в чём собственно её нетривиальность? Автор пакета должен суметь чётко
 > DS> сформулировать что необходимо его сервису для работы.
 > Нетривиальность вообще в создании такого дерева.

В смысле в создании дерева по меткам, или в проставлении меток
зависимости?
 
 > DS> Насчёт завязки на диск -- что это, например? Сервер БД на что больше
 > DS> завязан? IMHO сервер БД можно запускать как только смонтированы все
 > DS> разделы и подняты интерфейсы (если он не локальный).
 > то же самое можно сказать про большиснтво других сервисов.
 > Итак, fsck :), squid, smb
 > А в целом, да, ты прав, нужно какое-то другое деление.

squid часть времени своего запуска почти не насилует хард. Кроме того кэш
сквида может случайно быть на другом харде. А smb при запуске вообще вроде
почти ничего не делает (разве что конфиги читает).

 > DS> Для многопроцессорных систем польза от многопоточного запуска, IMHO,
 > DS> очевидна. 
 > Но не для hdd.

Ну на многопроцессных системах вполне может оказаться что данные разных
процессов на разных разделах. Тестировать это всё надо.
 
 > DS> Ещё можно вспонмить известный факт с многопроцессной компиляцией (make
 > DS> -jN), которая увеличивает скорость компиляции даже на однопроцессорных
 > DS> машинах.
 > Потому  что  тут  постоянно  запускаются  одни и те же программы
 > (gcc, make, ...), которые уже лежат в кэше.

Это да. Но, IMHO, основные задержки при запуске системы сейчас это
DNS-запросы (и прочая сетевая активность) во время поднятия сервисов, и
таки загрузка процессора теми же скриптами.

 > DS>  > В  сам  S-скрипт (те, которые лежат в init.d) добавляем еще одно
 > DS>  > поле  типа  как это сделано для chkconfig. В этом поле указываем
 > DS>  > класс скрипта - дисковый или нет.
 > DS> Тоже вариант. Только вот с классом скрипта непонятно -- как их делить?
 > DS> Какой у Bind'а? А если он обслуживают тучу зон? А у иксов?
 > Думать надо...

Мне кажется, что не удастся это разделить.
 
 > DS>  > Можно  пойти  дальше  и  ввести  еще  одно  поле  в  S-скрипте -
 > DS>  > зависимость  от  уже  стартовавшего  сервиса.  Реализация именно
 > DS>  > такого  способа  задания  зависимостей  не  представляет  вообще
 > DS>  > никакого труда.
 > DS> Собственно этим и можно в результате сделать точно ту схему, о которой я
 > DS> писал выше. Только тогда придётся шерстить все скрипты.
 > И?

Нужно чтобы всё работало даже для тех программ, которые об этой фиче не
знают. Если действительно сделать зависимостями по-умолчанию "все
предыдущие скрипты в списке", то действительно будет всё работать.
 
-- 
С уважением, Денис

http://freesource.info

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

Re[2]: [Comm] Re:

[ASA]

Hello Denis,

Saturday, May 10, 2003, 2:10:59 AM, you wrote:

DS>  > Как мы отметили ниже, такое можно реализовать без потери
DS>  > совместимости с SysV.
 
DS> В какой момент должен запускаться скрипт, если для него ничего не указано?
DS> Считать его зависимых от всех предыдущих по номеру?

Видимо, так.

Кстати, в RH и Debian есть вехи. Что-то типа - после S20 поднята
сеть, после S40 смонтированы все файловые системы.

DS>  > seek  test  ;). Пример - в той же вынде выделите побольше иконок
DS>  > на  рабочем  столе  и  нажмите  Enter  ;)  Поэтому  можно ввести
DS>  > ограничение на одновременную работу не более 4*CPU скриптов враз.

DS> Это конфигурируемо должно быть. По-умолчанию 4*CPU -- оптимум.

Главное - не забыть об этом.

DS>  > DS>  > отдельно   от  других  подобных  ему.  И  тут  может  возникнуть
DS>  > DS>  > нетривиальная  задача  развязки  обязательных  и  необязательных
DS>  > DS>  > зависимостей.
DS>  > DS> А в чём собственно её нетривиальность? Автор пакета должен суметь чётко
DS>  > DS> сформулировать что необходимо его сервису для работы.
DS>  > Нетривиальность вообще в создании такого дерева.

DS> В смысле в создании дерева по меткам, или в проставлении меток
DS> зависимости?

Если скрипт 3 связан нежесткой зависимостью со скриптом 2,
который не стартовал, потому что он жестко связан со скриптом 1,
выдавшим FAILED.


DS> Нужно чтобы всё работало даже для тех программ, которые об этой фиче не
DS> знают. Если действительно сделать зависимостями по-умолчанию "все
DS> предыдущие скрипты в списке", то действительно будет всё работать.
 
Именно поэтому сами скрипты должни связываться реализоваться
только через теги-комментарии а-ля chkconfig.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re:

[Denis Smirnov]

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

On Sat, May 10, 2003 at 01:15:04PM +0500, ASA wrote:

> DS> В какой момент должен запускаться скрипт, если для него ничего не указано?
> DS> Считать его зависимых от всех предыдущих по номеру?
> Видимо, так.
> Кстати, в RH и Debian есть вехи. Что-то типа - после S20 поднята
> сеть, после S40 смонтированы все файловые системы.

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

 > DS>  > seek  test  ;). Пример - в той же вынде выделите побольше иконок
 > DS>  > на  рабочем  столе  и  нажмите  Enter  ;)  Поэтому  можно ввести
 > DS>  > ограничение на одновременную работу не более 4*CPU скриптов враз.
 > DS> Это конфигурируемо должно быть. По-умолчанию 4*CPU -- оптимум.
 > Главное - не забыть об этом.

Угу. Хотя так как запускалка должна отслеживать результат выполнения
каждого скрипта, то для добавления ограничения по количеству работающих
процессов почти ничего писать не нужно. 
 
 > DS>  > DS>  > отдельно   от  других  подобных  ему.  И  тут  может  возникнуть
 > DS>  > DS>  > нетривиальная  задача  развязки  обязательных  и  необязательных
 > DS>  > DS>  > зависимостей.
 > DS>  > DS> А в чём собственно её нетривиальность? Автор пакета должен суметь чётко
 > DS>  > DS> сформулировать что необходимо его сервису для работы.
 > DS>  > Нетривиальность вообще в создании такого дерева.
 > DS> В смысле в создании дерева по меткам, или в проставлении меток
 > DS> зависимости?
 > Если скрипт 3 связан нежесткой зависимостью со скриптом 2,
 > который не стартовал, потому что он жестко связан со скриптом 1,
 > выдавшим FAILED.

То 3-й скрипт стартует.

Упрощённо алгоритм такой -- строится дерево. После этого создаётся список
узлов, у которых нет зависимостей. Из этого списка выбираются имена
скриптов для старта. После того, как скрипт завершит свою работу (с
каким-либо кодом завершения) смотрим на узел-родитель, и смотрим на тип
связи. В зависимости от результата выполнения скрипта, типа связи, наличия
других невыполненых зависимостей родителя либо ничего не делаем с
родителем, либо переносим его в список узлов готовых к выполнению. При
этом если FAILED скрипт, зависимость которого с родителем прямая, то
тогда родителю выставляется флаг FAILED, и, когда придёт время его
переноса в очередь для выполнения мы просто выдаём что он и не будет
выполняться.
 
 > DS> Нужно чтобы всё работало даже для тех программ, которые об этой фиче не
 > DS> знают. Если действительно сделать зависимостями по-умолчанию "все
 > DS> предыдущие скрипты в списке", то действительно будет всё работать.
 > Именно поэтому сами скрипты должни связываться реализоваться
 > только через теги-комментарии а-ля chkconfig.

Согласен.
 
-- 
С уважением, Денис

http://freesource.info

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

Re[2]: [Comm] Re:

[ASA]

Hello Denis,

Saturday, May 10, 2003, 8:56:44 PM, you wrote:

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

По существу вопроса мне сказать больше нечего - вроде все
понятно...

А  теперь  сермяжный  вопрос.  Для  чего  нужна  эта оптимизация
вообще?  ;)  Серверам с uptime от 50 до 600 суток - выигрыш в 30
секунд  на  выполнение  стартупа  -  совершенно  ненужная  вещь.
Рабочим  станциям  с  uptime  не  более  10-12 часов - все равно
непонятно,  зачем  оптимизировать.  Пришел  на  работу,  включил
машину,  пока  она "разогревается" - переодеваешься, беседуешь с
коллегами  и  т.п. Для домашней станции аналогично - пока греешь
завтрак и т.п.

Спрашивается - зачем экономим?

Поэтому:  идею  задать  _зависимости_  скриптов друг от друга (с
которой  я  согласен),  надо  подавать именно как способ указать
зависмости  скриптов,  а  не  как экономию времени запуска ОС за
счет  одновременного  выполнения  скриптов  (с чего и собственно
начиналось данное обсуждение).

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re[3]: [Comm] Re:

[Maksim Otstavnov]

Hello ASA,

Sunday, May 11, 2003, 1:30:01 AM, you wrote:

A> Спрашивается - зачем экономим?

A> Поэтому:  идею  задать  _зависимости_  скриптов друг от друга (с
A> которой  я  согласен),  надо  подавать именно как способ указать
A> зависмости  скриптов,  а  не  как экономию времени запуска ОС за
A> счет  одновременного  выполнения  скриптов  (с чего и собственно
A> начиналось данное обсуждение).

Воистину.

"Оптимизация" в Юниксах имеет долгую историю (вплоть до замены
initscripts компилируемыми программами), и ни разу я не помню, чтобы
это приводило к заметным результатам (кроме усложнения
администрирования).

А вопрос с зависимостью скриптов (точнее, со способами ее
формализации) действительно стоит поисследовать IMHO.

-- 
-- Maksim

Re: [Comm] Re:

[Denis Smirnov]

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

On Sun, May 11, 2003 at 10:58:46AM +0400, Maksim Otstavnov wrote:

 > "Оптимизация" в Юниксах имеет долгую историю (вплоть до замены
 > initscripts компилируемыми программами), и ни разу я не помню, чтобы
 > это приводило к заметным результатам (кроме усложнения
 > администрирования).

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

А по поводу серверов -- экономия минуты иногда может сэкономить нервы.
 
-- 
С уважением, Денис

http://freesource.info

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

Re[2]: [Comm] Re:

[ASA]

Hello Denis,

Sunday, May 11, 2003, 5:13:17 PM, you wrote:

DS> А с какого перепугу компиляция должна дать заметные результаты в этой
DS> задаче? Сами скрипты инициализации простенькие, их интерпретация занимает
DS> очень небольшое время от времени загрузки. А вот параллельный запуск может
DS> уменьшить время старта серьёзно.

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

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re:

[Denis Smirnov]

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

On Mon, May 12, 2003 at 08:48:28AM +0500, ASA wrote:

> DS> А с какого перепугу компиляция должна дать заметные результаты в этой
> DS> задаче? Сами скрипты инициализации простенькие, их интерпретация занимает
> DS> очень небольшое время от времени загрузки. А вот параллельный запуск может
> DS> уменьшить время старта серьёзно.
> DS> А по поводу серверов -- экономия минуты иногда может сэкономить нервы.
> Но это должно быть побочным результатом, имхо.

Думаю, что если некое улучшение не создаёт геморроя тем, кому оно не
нужно, то есть смысл его делать. 

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

http://freesource.info

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

Re[2]: [Comm] Re:

[ASA]

Hello Denis,

Monday, May 12, 2003, 4:46:42 PM, you wrote:

DS> Думаю, что если некое улучшение не создаёт геморроя тем, кому оно не
DS> нужно, то есть смысл его делать. 
Ты б лучше RFC дополнил. Есть отзывы, что типа поле after не
нужно - его типа с успехом заменяет сама S-нумерация.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re:

[Dmitry Alexeyev]

В сообщении от Понедельник 12 Май 2003 19:51 ASA написал(a):
> Hello Denis,
>
> Monday, May 12, 2003, 4:46:42 PM, you wrote:
>
> DS> Думаю, что если некое улучшение не создаёт геморроя тем, кому оно не
> DS> нужно, то есть смысл его делать.
> Ты б лучше RFC дополнил. Есть отзывы, что типа поле after не
> нужно - его типа с успехом заменяет сама S-нумерация.

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

WBR,
Dmitry

Re[2]: [Comm] Re:

[ASA]

Hello Dmitry,

Monday, May 12, 2003, 10:15:28 PM, you wrote:

>> DS> Думаю, что если некое улучшение не создаёт геморроя тем, кому оно не
>> DS> нужно, то есть смысл его делать.
>> Ты б лучше RFC дополнил. Есть отзывы, что типа поле after не
>> нужно - его типа с успехом заменяет сама S-нумерация.

DA> А нужна ли эта нумерация, если запуск параллельный?
Для совместимости со старыми скриптами и программами

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

DA> Лично меня все эти SXX
DA> всегда пугали до жути. 
:)


-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re:

[Denis Smirnov]

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

On Mon, May 12, 2003 at 08:51:56PM +0500, ASA wrote:

 > DS> Думаю, что если некое улучшение не создаёт геморроя тем, кому оно не
 > DS> нужно, то есть смысл его делать. 
 > Ты б лучше RFC дополнил. Есть отзывы, что типа поле after не
 > нужно - его типа с успехом заменяет сама S-нумерация.

Я его не видел. Вообще. Я о его существовании узнал только из личной
переписки (когда меня в чат пригласили). Оно в devel@, или я его здесь не
нашёл? Я на devel@ не подписан просто.
 
-- 
С уважением, Денис

http://freesource.info

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

Re[2]: [Comm] Re:

[ASA]

Hello Denis,

Tuesday, May 13, 2003, 1:11:09 AM, you wrote:

DS>  > DS> Думаю, что если некое улучшение не создаёт геморроя тем, кому оно не
DS>  > DS> нужно, то есть смысл его делать. 
DS>  > Ты б лучше RFC дополнил. Есть отзывы, что типа поле after не
DS>  > нужно - его типа с успехом заменяет сама S-нумерация.

DS> Я его не видел. Вообще. Я о его существовании узнал только из личной
Здесь. Я сознательно начал его с нового треда.

From: ASA <llb@udm.ru>
Message-ID: <1188331299.20030512092916@udm.ru>
To: Alexander Bokovoy Denis Smirnov <community@altlinux.ru>
Subject: [Comm] =?koi8-r?B?UkZDIM7BIM3PxMnGycvBw8nAIFN5c1Ygc3RhcnR1cA==?=
Date: Mon, 12 May 2003 09:29:16 +0500

Subject расшифрованный: [Comm] RFC на модификацию SysV startup

DS> переписки (когда меня в чат пригласили). Оно в devel@, или я его здесь не
DS> нашёл? Я на devel@ не подписан просто.

Я тоже. :))

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: Re[3]: [Comm] Re:

[Alexander Bokovoy]

On Sun, May 11, 2003 at 10:58:46AM +0400, Maksim Otstavnov wrote:
> Hello ASA,
> 
> Sunday, May 11, 2003, 1:30:01 AM, you wrote:
> 
> A> Спрашивается - зачем экономим?
> 
> A> Поэтому:  идею  задать  _зависимости_  скриптов друг от друга (с
> A> которой  я  согласен),  надо  подавать именно как способ указать
> A> зависмости  скриптов,  а  не  как экономию времени запуска ОС за
> A> счет  одновременного  выполнения  скриптов  (с чего и собственно
> A> начиналось данное обсуждение).
> 
> Воистину.
> 
> "Оптимизация" в Юниксах имеет долгую историю (вплоть до замены
> initscripts компилируемыми программами), и ни разу я не помню, чтобы
> это приводило к заметным результатам (кроме усложнения
> администрирования).
> 
> А вопрос с зависимостью скриптов (точнее, со способами ее
> формализации) действительно стоит поисследовать IMHO.
Теперь хотелось бы, чтобы кто-нибудь из участников обсуждения потратил еще
немного времени на сведение получившихся результатов в один небольшой RFC,
с которым можно было бы работать дальше.
-- 
/ Alexander Bokovoy
---
Well, I'm disenchanted too.  We're all disenchanted.
		-- James Thurber

Re: [Comm] Re:

[Denis Smirnov]

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

On Sun, May 11, 2003 at 02:30:01AM +0500, ASA wrote:

 > А  теперь  сермяжный  вопрос.  Для  чего  нужна  эта оптимизация
 > вообще?  ;)  Серверам с uptime от 50 до 600 суток - выигрыш в 30
 > секунд  на  выполнение  стартупа  -  совершенно  ненужная  вещь.

Дык я этот вопрос в начале и поднял :)
 
 > Рабочим  станциям  с  uptime  не  более  10-12 часов - все равно
 > непонятно,  зачем  оптимизировать.  Пришел  на  работу,  включил
 > машину,  пока  она "разогревается" - переодеваешься, беседуешь с
 > коллегами  и  т.п. Для домашней станции аналогично - пока греешь
 > завтрак и т.п.
 > Спрашивается - зачем экономим?

Дома, кстати, долгая загрузка нервирует. Так приятно было смотреть на то,
как быстро BeOS оживает.
 
 > Поэтому:  идею  задать  _зависимости_  скриптов друг от друга (с
 > которой  я  согласен),  надо  подавать именно как способ указать
 > зависмости  скриптов,  а  не  как экономию времени запуска ОС за
 > счет  одновременного  выполнения  скриптов  (с чего и собственно
 > начиналось данное обсуждение).

А зачем нужны эти зависимости? Только для того, чтобы не пытаться
запустить один сервис, когда тот, от которого он зависит, не смог
подняться? Или есть ещё какие-то преимущества?
 
-- 
С уважением, Денис

http://freesource.info


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

[Comm] Re:

[Michael Shigorin]

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

On Fri, May 09, 2003 at 03:12:57AM +0400, Denis Smirnov wrote:
> Для многопроцессорных систем польза от многопоточного запуска,
> IMHO, очевидна. 

Не уверен.  Субъективно -- там обычно в таймауты упирается, а не
в боттлонеки.

Т.е. быстрый взлет наиболее нужен на embedded, довольно-таки --
на столе.

У сервера обычно время самотестирования оборудования будет более
лимитирующим фактором, чем то, взлетит ли все на полсекунды
быстрее или нет.

С учетом того, что и на smp камням есть что делать.

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

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

Re: [Comm] Re:

[Denis Smirnov]

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

On Tue, May 13, 2003 at 10:10:57PM +0300, Michael Shigorin wrote:

 > Не уверен.  Субъективно -- там обычно в таймауты упирается, а не
 > в боттлонеки.
 > Т.е. быстрый взлет наиболее нужен на embedded, довольно-таки --
 > на столе.

/me очень хочет двухпроцессорную машину дома, и рано или поздно себе её
таки купит.

У меня вот инициализация SCSI-адаптера занимает времени больше, чем
загрузка линукса :(

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

http://freesource.info

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

Re[2]: [Comm] Re:

[ASA]

Hello Denis,

Wednesday, May 14, 2003, 1:29:16 AM, you wrote:


DS> У меня вот инициализация SCSI-адаптера занимает времени больше, чем
DS> загрузка линукса :(

Тогда никакая оптимизация линукса не поможет :))

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re:

[Denis Smirnov]

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

On Wed, May 14, 2003 at 08:19:18AM +0500, ASA wrote:

> DS> У меня вот инициализация SCSI-адаптера занимает времени больше, чем
> DS> загрузка линукса :(
> Тогда никакая оптимизация линукса не поможет :))

Поможет с виндузятниками скоростью загрузки меряться :) 

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

http://freesource.info

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

[Comm] Re:

[Michael Shigorin]

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

On Thu, May 08, 2003 at 11:13:58PM +0400, Denis Smirnov wrote:
>  > Если есть прикладные соображения -- лучше в devel@.
> У меня были только общие идеи. Для каждого стартового скрипта
> должно быть описание зависимостей -- после запуска какого
> скрипта можно запускать этот скрипт.

Это если делать, то не в скриптах, а в рулилке ими.

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

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

Re: [Comm] Re:

[ASA]

Hello Michael,

Wednesday, May 14, 2003, 12:08:44 AM, you wrote:

>> У меня были только общие идеи. Для каждого стартового скрипта
>> должно быть описание зависимостей -- после запуска какого
>> скрипта можно запускать этот скрипт.

MS> Это если делать, то не в скриптах, а в рулилке ими.

RFC прочти, да? Уже его написали :)

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

Re: [Comm] Re:

[Denis Smirnov]

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

On Tue, May 13, 2003 at 10:08:44PM +0300, Michael Shigorin wrote:

 > >  > Если есть прикладные соображения -- лучше в devel@.
 > > У меня были только общие идеи. Для каждого стартового скрипта
 > > должно быть описание зависимостей -- после запуска какого
 > > скрипта можно запускать этот скрипт.
 > Это если делать, то не в скриптах, а в рулилке ими.

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

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

http://freesource.info

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

[Comm] Re:

[Michael Shigorin]

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

On Wed, May 14, 2003 at 12:29:16AM +0400, Denis Smirnov wrote:
> /me очень хочет двухпроцессорную машину дома, и рано или поздно
> себе её таки купит.

/me и так имеет 2xPPro200, причем сейчас -- именно дома :))

On Wed, May 14, 2003 at 12:29:55AM +0400, Denis Smirnov wrote:
>  > >  > Если есть прикладные соображения -- лучше в devel@.
>  > > У меня были только общие идеи. Для каждого стартового скрипта
>  > > должно быть описание зависимостей -- после запуска какого
>  > > скрипта можно запускать этот скрипт.
>  > Это если делать, то не в скриптах, а в рулилке ими.
> Разумеется. Только информация о зависимостях должна быть где-то
> прописана, и это где-то, скорее всего, в скриптах.

Игорь Хомяков сегодня в devel вот что забросил:
http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/

Аккурат по Вашему варианту, причем вроде как уже сделанное.

Только imo -- кардинально все же слишком.

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

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

Re: [Comm] Re:

[Denis Smirnov]

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

On Wed, May 14, 2003 at 10:19:44PM +0300, Michael Shigorin wrote:

 >> /me очень хочет двухпроцессорную машину дома, и рано или поздно
 >> себе её таки купит.
 > /me и так имеет 2xPPro200, причем сейчас -- именно дома :))

Везёт :)
 
 > >  > >  > Если есть прикладные соображения -- лучше в devel@.
 > >  > > У меня были только общие идеи. Для каждого стартового скрипта
 > >  > > должно быть описание зависимостей -- после запуска какого
 > >  > > скрипта можно запускать этот скрипт.
 > >  > Это если делать, то не в скриптах, а в рулилке ими.
 > > Разумеется. Только информация о зависимостях должна быть где-то
 > > прописана, и это где-то, скорее всего, в скриптах.
 > Игорь Хомяков сегодня в devel вот что забросил:
 > http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/
 > Аккурат по Вашему варианту, причем вроде как уже сделанное.
 > Только imo -- кардинально все же слишком.

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

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

http://freesource.info

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

Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Andrii Dobrovolskii]

Vitaly Lugovsky wrote:

>On Mon, 28 Apr 2003, Mike Lykov wrote:
>  
>
>>Например, у него два CD-ROMа (читающий и пишущий), а на
>>рабочем столе (и
>>кстати в /etc/fstab) - только один.  Что делать?  Что читать?
>>    
>>
>
> Хм... Зачем это надо? Зачем два сидюковода? Ладно бы DVD +
>CD/RW...
>  
>
Виталий Вы одесит? Зачем на вопрос отвечать вопросом? Мало ли зачем два. 
Да просто исторически так сложилось. Что обязательно выбрасывать 
работающую железку?

>>1. Базовые операции в системе
>> 1.1. Оценка внешнего вида, элементов управления
>> 1.2. Операции с окнами
>> 1.3. Операции с файлами и папками, дисками (форматирование,
>>проверка и пр.)
>>    
>>
>
> Пользователю ЭТО надо?!?
>
> Да и настраивать систему - не юзерское барское дело. Этим
>холоп-админ обязан заниматься.
>  
>
Систему, может и не барское, а своё рабочее место - таки да. Да и на 
холопа ещё заработать надо.

>  
>
>>2. Офисная работа
>> 2.1. Работа с текстовыми документами
>> 2.2. Работа с электронными таблицами
>>    
>>
>
> От прям таки усем это надо?!?
>  
>
Увы, но  - да. Не все же только программируют. :) Основная масса именно 
пишет и подсчитывает на ПК.

>  
>
>>4. Безопасность и надежность
>> 4.1. Настройки сетевой безопасности по умолчанию
>> 4.2. Наличие антивирусов
>>    
>>
>
> 4.2 на фига?!?
>  
>
Да чтоб собственные данные не потерять. Они для пользователя гораздо 
ценнее системы. :) Что ему до того, что в правильно настроенной системе 
пользователь может уничтожить только себя любимого? Его только он и 
интересует.

>  
>
>> 5.5. Обработка графики
>> 5.6. Издательская работа
>>    
>>
>
> Это - для прохфессионалов. Только и исключительно.
>  
>
Ага, и все цифровые фотографии нести исключительно в фотосалон, а 
сканеры выкинуть на помойку... продолжим?

>  
>
>> 5.7. Обработка звука и видео
>>    
>>
>
> Та же фигня.
>  
>
Вот именно. что таже! ;)

Re: [Comm] Re: [Comm] [JT] дизайн дистрибутива ALJ "как в вындовс"

[Vitaly Lugovsky]

On Tue, 29 Apr 2003, Andrii Dobrovolskii wrote:

> > Хм... Зачем это надо? Зачем два сидюковода? Ладно бы DVD +
> >CD/RW...
> >
> >
> Виталий Вы одесит? Зачем на вопрос отвечать вопросом? Мало ли
> зачем два.
> Да просто исторически так сложилось. Что обязательно
> выбрасывать
> работающую железку?

 Любой вариант, который приходит мне в голову, кроме
SCSI-устройств, ведёт к потере производительности. Так что да,
выбрасывать. Или другу подарить.

> > Да и настраивать систему - не юзерское барское дело. Этим
> >холоп-админ обязан заниматься.
> >
> Систему, может и не барское, а своё рабочее место - таки да.
> Да и на
> холопа ещё заработать надо.

 Хех. Холоп завсегда дешевле выходит, чем собственные нервы.

> >>2. Офисная работа
> >> 2.1. Работа с текстовыми документами
> >> 2.2. Работа с электронными таблицами
> >
> > От прям таки усем это надо?!?
> >
> Увы, но  - да. Не все же только программируют. :) Основная
> масса именно
> пишет и подсчитывает на ПК.

 Я этой массы не видел... Основная масса решает очень даже
частные задачи, и в обобщённых супер-пупер-универсальных
инструментах вроде Офиса - не нуждаются.

> >> 4.2. Наличие антивирусов
> >
> > 4.2 на фига?!?
> >
> Да чтоб собственные данные не потерять.

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

> >> 5.5. Обработка графики
> >> 5.6. Издательская работа
> >
> > Это - для прохфессионалов. Только и исключительно.
> >
> Ага, и все цифровые фотографии нести исключительно в
> фотосалон, а
> сканеры выкинуть на помойку... продолжим?

 Что там обрабатывать? Воткнул камеру в USB, фотки автоматом
стекли в твой public_html, или куда там ещё желаешь...

Re: [Comm] Re: [Comm] [JT] дизайн ди стрибутива ALJ "как в в ындовс"

[Denis Smirnov]

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

On Tue, Apr 29, 2003 at 10:14:33AM +0300, Andrii Dobrovolskii wrote:

 > Систему, может и не барское, а своё рабочее место - таки да. Да и на 
 > холопа ещё заработать надо.

_Рабочее_ место? Самостоятельно?
 
 >>> 4. Безопасность и надежность
 >>> 4.1. Настройки сетевой безопасности по умолчанию
 >>> 4.2. Наличие антивирусов
 >> 4.2 на фига?!?
 > Да чтоб собственные данные не потерять. Они для пользователя гораздо 
 > ценнее системы. :) Что ему до того, что в правильно настроенной системе 
 > пользователь может уничтожить только себя любимого? Его только он и 
 > интересует.

В линуксе это нужно только если пользователь сам себе машину настраивает
:)
 
-- 
С уважением, Денис

http://freesource.info

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

Re: [Comm] Re: [Comm] [JT] дизайн ди стрибутива ALJ "как в в ындовс"

[Andrii Dobrovolskii]

Denis Smirnov wrote:

>On Tue, Apr 29, 2003 at 10:14:33AM +0300, Andrii Dobrovolskii wrote:
>
> > Систему, может и не барское, а своё рабочее место - таки да. Да и на 
> > холопа ещё заработать надо.
>
>_Рабочее_ место? Самостоятельно?
> 
>
Да. Под рабочим местом я понимаю домашний каталог пользователя. А не 
машину на которой он живет. Или Вы предлагаете по поводу смены обоев 
звать админа?

> >>> 4. Безопасность и надежность
> >>> 4.1. Настройки сетевой безопасности по умолчанию
> >>> 4.2. Наличие антивирусов
> >> 4.2 на фига?!?
> > Да чтоб собственные данные не потерять. Они для пользователя гораздо 
> > ценнее системы. :) Что ему до того, что в правильно настроенной системе 
> > пользователь может уничтожить только себя любимого? Его только он и 
> > интересует.
>
>В линуксе это нужно только если пользователь сам себе машину настраивает
>:)
> 
>
К машине это не имеет никакого отношения. Кто настраивает систему - 
разговор совершенно отдельный.

>  
>
Андрей

Re: [Comm] Re: [Comm] [JT] дизайн ди стрибутива ALJ "как в в ындовс"

[Denis Smirnov]

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

On Fri, May 02, 2003 at 01:40:37PM +0300, Andrii Dobrovolskii wrote:

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

Нет конечно. Хотя я бы подумал на тему "а нужно ли позволять пользователю
менять обои", особенно если эти самые обои давят на глаза. Я только
недавно перестал веселиться над некоторыми сотрудниками, которые повесили
себе фоны, от которых я через 5 минут устаю, и теперь жалуются что у них
глаза устают.
 
 > >>>> 4. Безопасность и надежность
 > >>>> 4.1. Настройки сетевой безопасности по умолчанию
 > >>>> 4.2. Наличие антивирусов
 > >>> 4.2 на фига?!?
 > >> Да чтоб собственные данные не потерять. Они для пользователя гораздо 
 > >> ценнее системы. :) Что ему до того, что в правильно настроенной системе 
 > >> пользователь может уничтожить только себя любимого? Его только он и 
 > >> интересует.
 > >В линуксе это нужно только если пользователь сам себе машину настраивает
 > >:)
 > К машине это не имеет никакого отношения. Кто настраивает систему - 
 > разговор совершенно отдельный.

Имеет. Вирусы приходят двумя путями -- с принесёнными программами, и через
интернет. Если пользователь приносит свой софт, то за это его надо бить по
голове статьями УК на тему "нарушений правил пользования сетью ЭВМ". А
чтобы вирусы не приходили через сеть, то нужна соответствующая настройка
машины (сделаная умным админом). Защитить линукс-машину многократно легче
виндовой, и, даже для существующих червей под линукс, антивирусы не нужны,
нужно вовремя патчи накладывать, и если патч наложен, то антивирус не
нужен.

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

http://freesource.info


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