[mdk-re] Logo for kernel

[Maksim Otstavnov]

Hello Andrei,

Sunday, January 14, 2001, 8:06:03 PM, you wrote:

AG> Еще раз, последний, хочу обратить внимание на одну сторону GUI.
AG> Устанавливаем, скажем, детонатор от nvidia. В свойствах десктопа видим
AG> кнопочки и т.д. Соответственно видим, что настраивается в драйвере и, самое
AG> главное, знаем _что_больше_не_настраивается_ничего.

Мимо кассы. Если при установке создается нормальный и исчерпывающе
самодокументированный скелет плоского конфигурационного файла (ау,
SVR4.2!), просмотрев его сверху вниз, мы знаем,
_что_больше_не_настраивается_ничего.

AG> Последнее может быть и не верно, например может-быть можно что-то
AG> явно прописать в регистратор, но это упрек не GUI как идее, а
AG> nVidia и виндам, где GUI столь же ущербен как и все остальное.

И точно так же, если скелеты плохо написаны или недодокументированы...

Давайте потопчемся на этом месте.

Основная проблема настроек какая? - Правильно, часто для решения
какой-то задачи ("настроить сеть", например) нужно хакать кучу
несвязанных файлов настройки, и хорошо, если в одном файле хотя бы
упомянут другой. HOW-TO и гайды администратора, в основном, и нужны,
чтобы проследить неочевидные связи одного с другим.

Вот в виндах в 1994 г. внедрили "реестр". Это такая большая помойка,
где (должны быть) собраны все настройки от программ, снесенных с
момента последней переустановки системы ;)

В самой идее есть здравый смысл. В следовых количествах.

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

Можно подумать в этом направлении. Вместо того, чтобы писать гуевые
прилады для настройки, что только индуцирует параноиков.

   (Вообще, все новое есть хорошо забитое старое. В смысле, на которое
   забили. Вышеприведенный набросок - просто применение кнутовских
   принципов literate programming к такому специфическому виду
   "программирования", как настройка системы.)

AG> Разговор о GUI более важен чем может показаться, поскольку хороший
AG> GUI подразумевает хорошую структурированность типа интерфейс -
AG> объект - страница свойств. Как раз по-этому у виндов GUI и
AG> паршивый. Но они над этим работают (или работали, а сейчас отходят
AG> от операционных систем вообще?).

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

Monday, January 15, 2001, 1:07:27 AM, Aleksey wrote:

>> Разговор о GUI более важен чем может показаться, поскольку хороший GUI
>> подразумевает хорошую структурированность типа интерфейс - объект - страница
>> свойств. Как раз по-этому у виндов GUI и паршивый. Но они над этим работают
>> (или работали, а сейчас отходят от операционных систем вообще?).
>> 
AN> А Вы читали статью Виктора Вагнера, ссылку на которую приводил Максим?
AN> Она весьма содержательна и написана убежденным сторонником Unix way.

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

AN> Я не со всем там согласен, но описано все стройно и ясно, а потому
AN> очень интересна.

Возможно, стоит сделать ее пересказ в менее эзотерических терминах?

AN>> Кстати, интересные фантазии на тему GUI -- Nautilus. Он пока крайне
AN>> сырой и можно оценить лишь концепцию.

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

-- 
-- Maksim