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

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

[Mike Lykov]

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

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

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

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

(с) Vladimir Yumashev

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

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

В том или ином пункте рассматриваются только приложения, 
идущие в комплекте или доступные в Internet в "готовом" виде - в виде rpm 
или deb файлов.  Приложения, доступные в виде исходных текстов, - не 
рассматриваются вообще.

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

Например, у него два CD-ROMа (читающий и пишущий), а на рабочем столе (и 
кстати в /etc/fstab) - только один.  Что делать?  Что читать?
Он согласен пользоваться при необходимости командной строкой.  Если ему 
толково объяснят чем терминальная сессия отличается от GUI и что это вообще 
за неприличное слово.
Он может быть и гуманитарием (философом, маркетологом, менеджером) и 
технарем (конструктором двигателей, например), но он _не_программист_, 
_не_сисадмин_, _не_компьютерный_nerd_ и кстати, не студент и не школьник.  
Последние двое в силу природного любопытства разберутся с чем угодно.

Я не буду рассматривать процедуру установки - это практически во всех 
дистрибутивах более-менее отлажено.

Итак, чем занимается "обычный средний пользователь" на компьютере.

1. Базовые операции в системе
 1.1. Оценка внешнего вида, элементов управления
 1.2. Операции с окнами
 1.3. Операции с файлами и папками, дисками (форматирование, проверка и пр.)
 1.4. Запуск и использование встроенных приложений
 1.5. Начальные настройки системы
  1.5.1. Добавление и удаление приложений
  1.5.2. Добавление и удаление шрифтов
  1.5.3. Настройка внешнего вида
  1.5.4. Клавиатура, мышь, дисплей
  1.5.5. Прочие настройки
 1.6. Получение справочной информации и документация
2. Офисная работа
 2.1. Работа с текстовыми документами
 2.2. Работа с электронными таблицами
 2.3. Организация работы электронными средствами
 2.4. Печать и управление принтерами
 2.5. Совместная работа через сеть (общие файлы и папки)
3. Работа с Internet
 3.1. Работа с Web
 3.2. Работа с электронной почтой
 3.3. Средства общения в real-time (ICQ, IRC и прочее)
 3.4. Доступ к провайдеру по PPP
4. Безопасность и надежность
 4.1. Настройки сетевой безопасности по умолчанию
 4.2. Наличие антивирусов
 4.3. Обновление системы
 4.4. Стабильность и надежность работы
5. Дополнительные опции
 5.1. Просмотр картинок
 5.2. Чтение HTML и PDF файлов
 5.3. Просмотр видео и ТВ
 5.4. Прослушивание аудио и FM
 5.5. Обработка графики
 5.6. Издательская работа
 5.7. Обработка звука и видео
 5.8. Дополнительные средства Internet
  5.8.1. Менеджеры закачек
  5.8.2. Пиринговые сети
  5.8.3. Средства аудио- и видео-конференций
 5.9. Поддержка оборудования
  5.9.1. Видео
  5.9.2. Мышь и клавиатура
  5.9.3. Звук
 5.10. Словари и переводчики



-- 
Mike

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 "как в вындовс"

[@ 2003-04-29 12:58 UTC (permalink / raw)]

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

[@ 2003-04-30 5:09 UTC (permalink / raw)]

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

[@ 2003-04-30 5:42 UTC (permalink / raw)]

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

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

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

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

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

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

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

[@ 2003-04-29 13:01 UTC (permalink / raw)]

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

[@ 2003-04-29 13:15 UTC (permalink / raw)]

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

[@ 2003-04-29 13:53 UTC (permalink / raw)]

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

[@ 2003-04-29 18:26 UTC (permalink / raw)]

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

[@ 2003-04-29 20:47 UTC (permalink / raw)]

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

[@ 2003-04-30 6:22 UTC (permalink / raw)]

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

[@ 2003-04-30 6:23 UTC (permalink / raw)]

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

[@ 2003-05-06 13:12 UTC (permalink / raw)]

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

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

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

[@ 2003-04-29 13:05 UTC (permalink / raw)]

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

[@ 2003-04-29 18:11 UTC (permalink / raw)]

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

[@ 2003-04-30 5:06 UTC (permalink / raw)]

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

[@ 2003-05-06 13:24 UTC (permalink / raw)]

Re: [Comm] Re:

[@ 2003-05-06 13:49 UTC (permalink / raw)]

[Comm] Re:

[@ 2003-05-07 11:30 UTC (permalink / raw)]

Re: [Comm] Re:

[@ 2003-05-07 12:33 UTC (permalink / raw)]

[Comm] Re:

[@ 2003-05-08 8:29 UTC (permalink / raw)]

Re: [Comm] Re:

[@ 2003-05-08 19:13 UTC (permalink / raw)]

Re[2]: [Comm] Re:

[@ 2003-05-08 22:06 UTC (permalink / raw)]

Re: [Comm] Re:

[@ 2003-05-08 23:12 UTC (permalink / raw)]

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 --]