GUI vs. текстовый конфиг (отрезано от: Нужна ли реклама GNU софту...)

[drBatty]

то я сразу привёл пример того, как при использовании plain text конфига никаких сообщений об ошибках нет.

а давайте не будем inittab трогать? что-нибудь попроще, инициализацию системы можно с лёгкостью завалить и с помощью ГУИ(пример про сетевые интерфейсы - выше). В конфиге сразу всё видно просто потому, что программист с лёгкостью может задать такое:

Код: Выделить всё

- processing configuration directory '/etc/proftpd.d'
- Fatal: unknown configuration directive 'гы' on line 144 of '/etc/proftpd.conf'

но ТОЛЬКО с конфигом, рисовать на каждую галку скрин, с подробным пояснением почему так делать нельзя, и как надо делать - никто не будет, и именно про это я и писал. Ни в каком страшном сне разработчикам proftpd не снилась директива 'гы', тем не менее всё работает корректно, как и ожидалось. При использовании ГУИ результат далеко не очевидный, причём пользователю даже толком не сформулировать свой вопрос в саппорт /на какой-нибудь форум/другу-гуру.

[diesel]

то я сразу привёл пример того, как при использовании plain text конфига никаких сообщений об ошибках нет.

а давайте не будем inittab трогать? что-нибудь попроще, инициализацию системы можно с лёгкостью завалить и с помощью ГУИ(пример про сетевые интерфейсы - выше). В конфиге сразу всё видно просто потому, что программист с лёгкостью может задать такое:

Код: Выделить всё

- processing configuration directory '/etc/proftpd.d'
- Fatal: unknown configuration directive 'гы' on line 144 of '/etc/proftpd.conf'

но ТОЛЬКО с конфигом, рисовать на каждую галку скрин, с подробным пояснением почему так делать нельзя, и как надо делать - никто не будет, и именно про это я и писал. Ни в каком страшном сне разработчикам proftpd не снилась директива 'гы', тем не менее всё работает корректно, как и ожидалось. При использовании ГУИ результат далеко не очевидный, причём пользователю даже толком не сформулировать свой вопрос в саппорт /на какой-нибудь форум/другу-гуру.

предположим что у нас "правильная" GUI, которая знает что в это поле ввода можно вводить только [A-Za-z1-9.-_], и в случае всего остального оно нам говорит о неправильности ввода.

Кстати, GUI не обязательно должна давать возможность настроить все и вся, достаточно дать возможность настроить наиболее нужные при обычном использовании фичи. Для вашего же ftp: разрешить/запретить анонимный вход, папка(и) которые мы будем шарить, права на шаренную папку. Все остальное можно выставить в какие-то разумные дефолты, если человеку будет надо поменять - он посмотрит в конфиге. Warderer правильно заметил - в ГУИ может быть легко решать простые задачи ... зачем тогда ГУИ усложнять?

[Goodvin]

Ещё раз спрашиваю: почему на основании некоторого количества GUI (к тому же не самого "прямого") Вы делаете вывод о том, что ВСЕ GUI такие?
Вы ни разу не видели программ с GUI, где даже логи показываются в специальном окошечке???

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

А вот с текстовыми конфигами всё строго наоборот.
Неудобных/нечитаемых/недокументированных конфигов, либо тех, информацию по которым нельзя найти тут же в системе man-ов, ничтожно мало по сравнению с количеством хороших удобных конфиг-файлов.
Потому что для того, чтобы сделать конфиг НЕУДОБНЫМ и перечеркнуть все удобства самого устройства простого текстового файла, надо специально стараться навредить пользователю.

И это мнение не только мое личное, это объективное наблюдение многих людей, работавших намало времени с большим количеством разных систем.

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

Заодно напоминаю Вам, что мы говорим лишь о GUI, используемом исключительно для настройки/изменения конфигурации программ, а не GUI для выполнения функциональных задач.
А то Вас и Ваших сторонников уже явно несет не в ту сторону.
Степень алогичности ваших заявлений уже подходит к критической черте.
Будьте внимательнее, наш уважаемый тролль.

[Goodvin]

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

[drBatty]

Warderer правильно заметил - в ГУИ может быть легко решать простые задачи ... зачем тогда ГУИ усложнять?

+1024
идеальный ГУИ - с одной кнопкой(я уже предупреждение получил, за то что сказал какой )

Потому что для того, чтобы сделать конфиг НЕУДОБНЫМ и перечеркнуть все удобства самого устройства простого текстового файла, надо специально стараться навредить пользователю.

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

[diesel]

Warderer правильно заметил - в ГУИ может быть легко решать простые задачи ... зачем тогда ГУИ усложнять?

+1024
идеальный ГУИ - с одной кнопкой(я уже предупреждение получил, за то что сказал какой )

http://stuffthathappens.com/blog/wp-conten.../simplicity.png

Вот где-то так.
:-)

[Ben Aceler]

В том-то и дело, что нет. Поэтому я один раз создал конфиг и забыл. Более того, конфиг могу выложить сюда и любой его вставит. Это гораздо проще, чем объяснять последовательность кнопок в pppoeconf, особенно когда последний раз конфигурировал его два года назад.

Ага, "любой вставит". А если у него ядро другое? И параметра MTU в нём нет вообще, а есть ActiveMTU, DefaultMTU и ещё парочка каких-нибудь MTU?

Вы троллить перестанете? Давайте, расскажите нам, как вы будете объяснять где найти галку в GUI, если там вместо MTU есть " ActiveMTU, DefaultMTU и ещё парочка каких-нибудь MTU".

Ничего, только мы тут говорим о том, что GUI лучше конфигов, а вы предлагаете пользоваться конфигом вместо того, чтобы объяснять как сделать то же самое с помощью GUI. Т.е. использование готового конфига _вместо_ GUI в данном случае предпочтительнее. ЧТД.

Нет. Потому что Вы в данном случае ВООБЩЕ НИЧЕГО не объясняете.
Вы выкладываете конфиг. И всё.
Точно также можно выложить программу в бинарной форме и написать: "запусти и всё тебе сделается само".

Именно. Я ничего не буду объяснять, не буду напрягаться рассказывать как найти этот гуй, не буду заниматься выяснением, почему у него галки не нажимаются. Выкладываю конфиг. И всё.

[watashiwa_daredeska]

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

Скажите, вы действительно считаете, что трех слов в label'е достаточно для понимания того, что делает настройка? Или все-таки документацию надо почитать?

В случае текстового конфига vi /etc/passwd, смотрим. Комментариев нет. Ну имя пользователя/пароль, допустим, ещё можно догадаться просто глядя в содержимое. А вот потом в каком порядке GID/UID или UID/GID? Надо либо твёрдо это знать, либо лезть в документацию. Т.е. всё как я и говорил с самого начала.

Я вам даже больше скажу, отредактировав /etc/passwd, вы, скорее всего, не добавите пользователя. Уже лет 10 как. По крайней мере, "недостаточно добавите", чтобы он мог залогиниться.

0. adduser newuser

Ну вот видите... Не то что какие-то параметры - правильное название воспроизвести и то затруднительно
useradd вообще-то.

У вас YaST, у меня adduser.

На самом деле пример АБСОЛЮТНО мимо кассы. Ибо useradd это программа, а запуск программы - это НЕ правка plain text конфига в текстовом редакторе. Несогласны?

Вы в курсе что такое chroot? /etc/passwd в chroot'е вы тоже YaST'ом рулите?

[watashiwa_daredeska]

Естественно "GUI -- это лишь пришлепка сбоку". Точно также, как и текстовые конфиги. Или Вы хотите сказать, что система построена на взаимодействии текстовых конфигов между собой?

В оригинале, Unix построен на взаимодействии программ через текстовые файлы, не только конфиги. Текстовый файл -- универсальный интерфейс. GUI конфигураторы -- это пришлепка сбоку для превращения универсального инструмента в многофункциональный прибор.

Более того - init вообще эту ситуацию за ошибку не считает, хотя runlevel 8 в текущей конфигурации Линукс систем не имеет смысла.

Имеет.

Ещё раз спрашиваю: почему на основании некоторого количества GUI (к тому же не самого "прямого") Вы делаете вывод о том, что ВСЕ GUI такие?

Я когда-то давно занимался разработкой GUI и по молодости лет всегда старался сделать "идеальный" GUI: чтоб данные валидировал, чтоб настроить можно было все, что можно, чтоб контекстная справка была и т.п. Могу сказать, что во многих случаях это практически нерешаемая задача. Сложность GUI-конфигуратора часто начинает превышать сложность того, что конфигурируется. С конфигами все на порядки проще реализуется. Т.к. программисты по сути своей ленивы, я делаю очень простой вывод -- хороших конфигов на порядки больше, чем хороших GUI-конфигураторов.

Вы ни разу не видели программ с GUI, где даже логи показываются в специальном окошечке???

Знаете, я логи редко читаю просто так. Слишком много. А так как в этом окошке обработать логи нормальными *nix-средствами не представляется возможным, то лично я засчитываю такое окошко в большой минус. Наличие такого окошка говорит о том, что разработчику было лень довести разработку GUI-конфигуратора до конца: кроме галочек, сделать еще и вразумительное сообщение об ошибке, а не заставлять пользователя разбирать эту абракадабру.

REXX же глобален. Любое приложение (если оно, конечно, не извернулось адским образом и вообще не использовало никаких системных примитивов) получает некий базовый комплект возможностей по управлению от рождения. Плюс к этому может само добавить некоторое подмножество функций для управления собой. И никаких "эта программа использует Lisp, а эта - Python, как их, блин, скрестить-то, я ж только shell знаю???"

А, ну это обычный "фашизм" со стороны среды. Такое и в Linux можно сделать. Проблема осложняется только тем, что в Linux много приложений, и далеко не все будут исользовать этот framework, а значит не получится универсального управления GUI, только частный случай, такое и сейчас найдется. Примерно, как сейчас нет средств универсально установить "тему".

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

Какие данные, в какой памяти, да еще когда программа не запущена?!

[Goodvin]

Потому что для того, чтобы сделать конфиг НЕУДОБНЫМ и перечеркнуть все удобства самого устройства простого текстового файла, надо специально стараться навредить пользователю.

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

Угу, только вот oneq сотоварищи считают, видимо, что такие GUI рождаются сами по себе по волшебному мановению любого ламера, боящегося простого текстового файла.
Там кроме дизайна важна еще и эргономика, и логичность, и легкость восприятия, и много чего еще кроме функционала.

[oneq]

а если подвигаю?

То я не удивлюсь.
Я же не говорю о том, что это невозможно в принципе.
Разговор зашёл с сообщения watashiwa_daredeska о том, что на настоящий момент он не видел средств, позволяющих автоматизировать произвольно взятое GUI без "специальных припрыжек" со стороны авторов этого GUI.
Я не знаю, как подвигать окошки в KDE через шелл. Возможно, это очень просто и надо всего лишь отредактировать какой-либо файл, отражающий текущее состояние KDE (как файлы в /proc отражают состояние ядра). Возможно нужно использовать какой-то встроенный в KDE язык. Но факт в том, что это всё то же самое - авторы KDE должны были оставить эти самые "припрыжки" для этого.
"Припрыжки" для разных программ будут отличаться. И методы, применимые для подвижки окон в KDE, вряд ли подойдут для какого-нибудь BlackBox.
На основании этого watashiwa_daredeska делает вывод о том, что GUI автоматизируем, но автоматизируем весьма сложно, в отличие от plain text конфигов, автоматизируемых очень легко. Моя позиция заключается в том, что большинство просто не видело ТАКИХ GUI. Я тоже не видел. По Амиге я только читал несколько книжек (о чём сразу честно сказал).
И ещё про Амигу вот:

Сидит себе софт, открывает "порты сообщений", есть стандартные порты у кнопок GUI, есть более высокоуровневое API которое экспортируется стандартному системному языку REXX. Можно записать эти скрипты, как в Маке в Automator и AppleScript, и проиграть потом. "порты" -- поддерживаются стандартной ОО GUI библиотекой, то есть для поддержки "скриптования" программисту ничего делать не надо. Как в Tcl/Tk, создали окно -- теперь можем из другого приложения скомандовать "нажать кнопку"

Тоже средство связать простые GUI приложения на 1 задачу и совместно взаимодействовать

©http://www.linux.org.ru/view-message.jsp?msgid=2498602&page=3#2500241
Если прочитать статью True Unix GUI то можно легко заметить, что те требования, которые выдвинуты в статье во многом были реализованы ещё в далеком 1987(!) году.

но как определить координаты кнопки? Это ж надо знать какая тема установлена, какой там размер кнопок, какое разрешение экрана и т.д. Куча дополнительной работы скрипту, вместо которой можно просто внести изменения в текстовый конфиг.

Вопрос на засыпку: а Вы когда другим объясняете как что сделать в GUI тоже говорите: "перемести курсор мышки на 120, 305 в относительных координатах и нажми левую кнопку" или всё же "нажми кнопку ОК"?

Подитожу: ГУЙ не из астрала появляется, его делать надо. И чем лучше гуй, тем сложнее его делать. Сделать плохой гуй легче, чем хороший, что и приводит к огромному количеству плохих гуев.

Всё правильно. Естественно, GUI ниоткуда не появится и, естественно, его надо кому-то делать.
Но я и не говорил, что GUI обязан быть и точка. Я лишь говорил о том, что через GUI настроить обычно проще. Т.е. проблема рассматривается на самом деле с другого конца
Никто не обязаны приделывать к своим программам GUI, если он этого не желает по каким-либо причинам, в том числе и по трудозатратным.

В конфиге сразу всё видно просто потому, что программист с лёгкостью может задать такое:

Код: Выделить всё

- processing configuration directory '/etc/proftpd.d'
- Fatal: unknown configuration directive 'гы' on line 144 of '/etc/proftpd.conf'

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

Интересно у Вас как-то.... Получается что на каждую опцию написать что-то вроде: "Unknown value "1" for param SomeParam on line 204 of '/etc/some.prog.conf'. Only "yes" or "no" allowed" это несложно, а проделать то же самое в GUI религия запрещает???
И зачем "на каждую галку скрин"? Есть более другие способы, гораздо более удобные, чем статическая картинка.
Вы, например, в IDE хоть раз работали? И как там со списком допущенных в тексте программы ошибок? Скринами IDE не завалило?

Ни в каком страшном сне разработчикам proftpd не снилась директива 'гы', тем не менее всё работает корректно, как и ожидалось. При использовании ГУИ результат далеко не очевидный, причём пользователю даже толком не сформулировать свой вопрос в саппорт /на какой-нибудь форум/другу-гуру.

При использовании GUI у пользователя скорее всего не будет возможности внести директиву 'гы' в конфигурацию.
С вопросом на форум вообще непонятно. Преимущества текстового конфига тут совершенно невидны. Приведённое Вами сообщение не относится к конфигу - оно относится к программе. Если программа "молчит в тряпочку" - будете выкладывать конфиг целиком. Точно также в GUI конфигураторе - никто не мешает взять ХРАНИЛИЩЕ настроек и предоставить его на суд общественности. Это, повторяю, НЕ вопрос КОНФИГУРИРОВАНИЯ, это вопрос ХРАНЕНИЯ настроек.

А вот с текстовыми конфигами всё строго наоборот.
Неудобных/нечитаемых/недокументированных конфигов, либо тех, информацию по которым нельзя найти тут же в системе man-ов, ничтожно мало по сравнению с количеством хороших удобных конфиг-файлов.
Потому что для того, чтобы сделать конфиг НЕУДОБНЫМ и перечеркнуть все удобства самого устройства простого текстового файла, надо специально стараться навредить пользователю.

drBatty просил попроще... Ну что же, попроще так попроще. Берём PureFTPD, открывает pureftpd.conf
Видим параметры AnonymousOnly и NoAnonymous. Оба подразумевают бинарную систему параметров yes/no. Т.е. можно установить оба параметра в yes и получить бесполезный сервер. Это попадает под "специально стараться навредить пользователю"?

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

Заметьте - я Вам говорю уже второй раз о том, что я нигде не говорил о том, что plain text конфиги надо изжить как класс.
Первоначальное утверждение было и осталось прежним: настроить по текстовым конфигам чаще наоборот сложнее.
Также были приведены аргументы: необходимо либо помнить, либо читать.
В сторону первых понесло именно фанатов plain text'а. Вместо того, чтобы убедительно доказать, что знать надо меньше и потеря времени на чтение не требуется началось "а GUI сложно автоматизировать", "а настройки сделанные GUI нельзя скопировать", "а откуда я знаю, что значит эта кнопка" и прочие подобные заявления, которые к самому процессу конфигурирования имеют второстепенное отношение, а относятся прежде всего к формату хранения настроек.
Единственный разумный довод, относящийся непосредственно к конфигурированию пока что был только "нельзя найти "галочку" поиском". Согласен. Хотя и есть GUI, в которых можно.

Давайте, расскажите нам, как вы будете объяснять где найти галку в GUI, если там вместо MTU есть " ActiveMTU, DefaultMTU и ещё парочка каких-нибудь MTU".

(Пути до параметров взяты с потолка)
Открой Компьютер - Центр управления, "Настройка сети", "Дополнительно", в поле подписанное ActiveMTU вбей значение 1400, нажми ОК.
Что здесь сложного?

Именно. Я ничего не буду объяснять, не буду напрягаться рассказывать как найти этот гуй, не буду заниматься выяснением, почему у него галки не нажимаются. Выкладываю конфиг. И всё.

Т.е. по прежнему проводим сравнение в заведомо неравных условиях.

[watashiwa_daredeska]

Пока никто не показал, что конфигурирование через текстовый файл проще, чем через GUI конфигуратор.
Сторонники plain text конфигов приводят доводы, которые далеко не напрямую относятся именно к настройке.

Пример 1. Две машины, обе Debian unstable (или еще чего) одной версии. Одна (A) с выходом в интернет, другая (B) без. Задача: обеспечить наиболее беспроблемное (т.е. через стандартный менеджер пакетов дистрибутива) управление софтом на машине B (установка, удаление, обновление) из сетевых репозитариев. Каково ваше решение с GUI и каковы трудозатраты?

Пример 2. 2 DNS не хотят работать вместе

[oneq]

Скажите, вы действительно считаете, что трех слов в label'е достаточно для понимания того, что делает настройка? Или все-таки документацию надо почитать?

Что Вам не понятно из этих слов: "Username", "Password", "Groups"? Какую документацию надо прочитать, чтобы понять, что они означают?

Я вам даже больше скажу, отредактировав /etc/passwd, вы, скорее всего, не добавите пользователя. Уже лет 10 как. По крайней мере, "недостаточно добавите", чтобы он мог залогиниться.

Я про это скромно умолчал. А то сторонники править /etc/passwd, /etc/shadow, /etc/group совсем огорчатся

У вас YaST, у меня adduser.

Нет. Никаких adduser.
У меня конфигуратор. У Вас - текстовые конфиги и vi для их редактирования. Или Вы уже не фанат конфигурирования через plain text?

Вы в курсе что такое chroot?

Не имею об этом ровно никакого понятия.

В оригинале, Unix построен на взаимодействии программ через текстовые файлы, не только конфиги. Текстовый файл -- универсальный интерфейс. GUI конфигураторы -- это пришлепка сбоку для превращения универсального инструмента в многофункциональный прибор.

Где и какой текстовый файл создаётся при выполнении ls -a | grep some_text?
Какие текстовые файлы передаются через сокеты?
С каких пор /dev/hda стал текстовым файлом?

Имеет.

Где об этом можно прочитать? В документации указано, что последний - 6.

Знаете, я логи редко читаю просто так. Слишком много. А так как в этом окошке обработать логи нормальными *nix-средствами не представляется возможным, то лично я засчитываю такое окошко в большой минус. Наличие такого окошка говорит о том, что разработчику было лень довести разработку GUI-конфигуратора до конца: кроме галочек, сделать еще и вразумительное сообщение об ошибке, а не заставлять пользователя разбирать эту абракадабру.

Позвольте поинтересоваться, на основании чего сделан вывод о том, что "разработчику было лень довести разработку GUI-конфигуратора до конца"? Вы, опять же, никогда не видели программ, которые показываю лог просто в качестве ещё одной возможности?

А, ну это обычный "фашизм" со стороны среды.

Скажите, а умение читать со stdin (чтобы пользователь мог нарисовать ls -a | grep some_text) это не "фашизм"?
А POSIX, FHS и прочее?

Какие данные, в какой памяти, да еще когда программа не запущена?!

Переменные окружения.

[watashiwa_daredeska]

©http://www.linux.org.ru/view-message.jsp?msgid=2498602&page=3#2500241
Если прочитать статью True Unix GUI то можно легко заметить, что те требования, которые выдвинуты в статье во многом были реализованы ещё в далеком 1987(!) году.

Проблема только в том, что в этой статье не предусматривается GUI для полноценного конфигурирования, а предусматриваются очень даже текстовые скрипты. GUI там все также пришлепнуто сбоку, в том смысле, что для наболее часто изменяемых опций в GUI выносятся кнопочки и галочки, а неварьируемые параметры хранятся в текстовом конфиге/скрипте. Я себе такую фиговину сделал на Tcl/Tk для запуска mplayer -- три галочки и кнопка, но это не конфигуратор.

Вопрос на засыпку: а Вы когда другим объясняете как что сделать в GUI тоже говорите: "перемести курсор мышки на 120, 305 в относительных координатах и нажми левую кнопку" или всё же "нажми кнопку ОК"?

Ответ на засыпку: а вы когда-нибудь пробовали реализовать "нажми кнопку OK"? Через GUI, а не скриптом через API, чтобы это работало для любого GUI-приложения.

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

[watashiwa_daredeska]

Что Вам не понятно из этих слов: "Username", "Password", "Groups"? Какую документацию надо прочитать, чтобы понять, что они означают?

При наличии только этих трех полей, лично мне неплохо было бы почитать, как через "Groups" определяется умолчательная группа.

Нет. Никаких adduser.
У меня конфигуратор. У Вас - текстовые конфиги и vi для их редактирования. Или Вы уже не фанат конфигурирования через plain text?

Я не фанат, я сторонник наличия нормально документированных конфигов. При желании, я могу состряпать собственный скрипт, который будет править /etc/password сотоварищи так, как мне надо. К счастью, кое-кто уже написал скриптики, облегчающие эту задачу и поделился ими с общественностью. Не поделился бы -- самому написать не проблема, даже с примитивненьким GUI. С непримитивненьким придется повозиться побольше.

Где и какой текстовый файл создаётся при выполнении ls -a | grep some_text?

Тут создается pipe, по которому гонятся текстовые данные. Грубо говоря, pipe -- урезанный вариант файла, во всяком случае, API то же самое. При желании можно вспомнить еще FIFO, которые присутствуют в файловой системе, да и сами pipe присутствуют в /proc.

Какие текстовые файлы передаются через сокеты?

Любые. Например, HTML

С каких пор /dev/hda стал текстовым файлом?

С тех пор, как я сделал cat Voyna_i_mir.txt >/dev/hda

Где об этом можно прочитать? В документации указано, что последний - 6.

man init

Runlevels 7-9 are also valid, though not really documented. This is because "traditional" Unix variants don’t use
them.

[Goodvin]

Первоначальное утверждение было и осталось прежним: настроить по текстовым конфигам чаще наоборот сложнее.
Также были приведены аргументы: необходимо либо помнить, либо читать.

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

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

[oneq]

Проблема только в том, что в этой статье не предусматривается GUI для полноценного конфигурирования, а предусматриваются очень даже текстовые скрипты. GUI там все также пришлепнуто сбоку, в том смысле, что для наболее часто изменяемых опций в GUI выносятся кнопочки и галочки, а неварьируемые параметры хранятся в текстовом конфиге/скрипте. Я себе такую фиговину сделал на Tcl/Tk для запуска mplayer -- три галочки и кнопка, но это не конфигуратор.

Почитайте её получше. Там не предусматривается GUI именно для конфигурирования. Там говорится об УНИВЕРСАЛЬНОМ, управляемым практически любым способом GUI. Естественно, что с помощью данного GUI можно делать "полноценное конфигурирование". Вы же не будете утверждать, что шелл - это средство только для полноценного конфигурирования.

Ответ на засыпку: а вы когда-нибудь пробовали реализовать "нажми кнопку OK"? Через GUI, а не скриптом через API, чтобы это работало для любого GUI-приложения.

Для абсолютно любого в настоящий момент сделать невозможно.
Точно также, как найти позицию этой самой кнопки. Ибо есть web-интерфейсы, есть flash, есть просто тупо картинка, а нажатия обрабатываются совсем другими механизмами. Везде пользователь будет видеть кнопку, но не везде она будет на самом деле и уж тем более не всегда можно будет получить хоть какой-то интерфейс для управления ею. Но я думаю Andrew S имел в виду совсем не это

При наличии только этих трех полей, лично мне неплохо было бы почитать, как через "Groups" определяется умолчательная группа.

А с чего Вы взяли, что полей будет только три? Я лишь спросил у Вас, что непонятного в этих словах.
Для "умолчательной группы" может быть как в YaST отдельное поле. Или специальное обозначение в списке. Или Вы опять скажете, что непонятно словосочетание default group или отдельное слово default?

Я не фанат, я сторонник наличия нормально документированных конфигов.

В чём проблема? Вы считаете, что существование GUI конфигураторов автоматически исключает существование нормально документированных конфигов?

Тут создается pipe, по которому гонятся текстовые данные. Грубо говоря, pipe -- урезанный вариант файла, во всяком случае, API то же самое. При желании можно вспомнить еще FIFO, которые присутствуют в файловой системе, да и сами pipe присутствуют в /proc.

"API то же самое" ещё не означает что это текстовый файл

Любые. Например, HTML

Это что же теперь бинарники (ну ежели я, например, бинарный файл по ftp скачиваю) при передаче преобразуются в текст??? Как удивительно!!! : )

С тех пор, как я сделал cat Voyna_i_mir.txt >/dev/hda

А less /dev/hda что показывает?

Runlevels 7-9 are also valid, though not really documented. This is because "traditional" Unix variants don’t use them.

Забавно. Не знал. Особенно радует "not really documented".

Вот и чудненько.
Теперь либо обосновываем данное процитированное заявление, либо признаем, что намеренно вводим участников форума в заблуждение со всеми вытекающими.
Не забываем обосновать с фактами и цифрами и слова про "чаще", и про то, что GUI якобы не требует ни помнить, ни читать документацию.

Драгоценный, Вы рехнулись или только что проснули после 11 дневного сна? Или кто-то вместо Вас все эти дни на форуме писал?
Раз уж Вы не можете не сотрясать воздух своими утверждениями о том, насколько Вы хорошо овладели логикой, то может быть поясните, по какой такой специально выдуманной логике спорят с ТЕЗИСАМИ (т.е. с кратко сформулированными основными мыслями), а не с самим утверждением? Goodvin logic special edition for oneq?
Я только что проверил - первый пост и все последующие прекрасно доступны. Так что потрудитесь-ка сперва оформить свои претензии так чтобы они хотя бы формально выглядели логично.
Более того - не покажете ли в теме то место, где я говорил о том что GUI вообще не требует помнить хоть что-то или читать вообще какую бы то ни было документацию?

Или может не будем затягивать и сразу в администрацию обратимся? Заодно, глядишь, также наконец-то найдём то место где я доказывал ущербность идеологии текстовых конфигов как таковых и выставлял GUI как вселенскую панацею.

[Goodvin]

oneq, уподобляться Вам и соревноваться в софистике и подмене понятий я не намерен.
Разумно вести дискуссию и услышать то, что Вам говорят собеседники, Вы не желаете, что доказали уже не только мне на страницах этой самой темы.
Аргументы по сути обсуждаемого вопроса я Вам уже сообщал, можете смело перечитать тему с самого начала и освежить.
Теперь, учитывая Ваше "неспортивное" поведение, от обсуждения с Вами сути вопроса "GUI против тектсовых конфигов" я вынужден устраниться и задавать Вам вопросы о несоответствии Вашего поведения правилам форума.
Увы.

Так Вы будете отказываться от своих слов, жонглируя "тезисами" и "утверждениями", или все-таки обоснуете свои высказывания ?
Я жду.

[/dev/random]

Тут создается pipe, по которому гонятся текстовые данные. Грубо говоря, pipe -- урезанный вариант файла, во всяком случае, API то же самое. При желании можно вспомнить еще FIFO, которые присутствуют в файловой системе, да и сами pipe присутствуют в /proc.

"API то же самое" ещё не означает что это текстовый файл

Даже не "грубо говоря", а файл и есть. В unix любые каналы, сокеты и прочее суть файлы. А также устройства (блочные и символьные), каталоги и т.д. Всё это файлы. Причём официально, а не "грубо говоря".

[watashiwa_daredeska]

Там говорится об УНИВЕРСАЛЬНОМ, управляемым практически любым способом GUI. Естественно, что с помощью данного GUI можно делать "полноценное конфигурирование". Вы же не будете утверждать, что шелл - это средство только для полноценного конфигурирования.

Ответ есть прямо в статье:

Таким образом, складывается концепция принципиально нового подхода к устройству десктопной OS, которая состоит в следующем:

Имеется базовый скриптовый язык, имеющий графический интерфейс. Все необходимые компоненты реализуются как расширения для этого языка.

Мне кажется, что идеальным языком для реализации такой системы является Tcl.

Так что, не любым способом, а вполне себе скриптами.

В чём проблема? Вы считаете, что существование GUI конфигураторов автоматически исключает существование нормально документированных конфигов?

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

Это что же теперь бинарники (ну ежели я, например, бинарный файл по ftp скачиваю) при передаче преобразуются в текст??? Как удивительно!!! : )

Давайте не будем путать то, что принято с тем, что возможно. Мы говорим о базовом подходе *nix-систем. Если не верите мне, вот вам цитата из любимого вами Vitus'а:

Каковы же составляющие интерфейса командной строки Unix, которые оказались в свое время настолько удачные, что живут уже 30 лет, и до сих пор находится немало людей, предпочитающих их разнообразным GUI?

На мой взгляд их четыре:

1. Универсальная форма представления информации — текстовый файл, понимаемый как последовательность символов, некоторые из которых имеют специальный смысл — разделяют строки(записи), поля и слова. Его командно-строчные программы выдают на экран человеку (stdout), его же ожидают в качестве ввода (stdin). Не будь этого стандарта бесполезен был бы следующий пункт

А less /dev/hda что показывает?

Не поверите, наверно, но показывает "Войну и мир".

[oneq]

oneq, уподобляться Вам и соревноваться в софистике и подмене понятий я не намерен.

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

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

Это не так.
Все аргументы были внимательно прочитаны, обдуманы и даже сказано чем они не устраивают.
Не я же виноват, что фанаты plain text конфигов говорят в основном не о том, как пользователь будет в текстовом редакторе править конфиг, а о совершенно других вещах, которым наличие GUI-конфигуратора в общем случае вообще никак не мешает.

Так Вы будете отказываться от своих слов, жонглируя "тезисами" и "утверждениями", или все-таки обоснуете свои высказывания ?

Прекратите дурака валять. Мои высказывания давным-давно обоснованы.
Обосновывать Ваши фантазии (а обосновать Вы предлагаете не мои слова, а именно Ваши фантазии) я не собираюсь.
Во-первых, потому что это Ваши фантазии - вот Вы их и обосновывайте.
Во-вторых, из опыта предыдущих бесед известно только одно: обосновать что-либо отличающееся от Вашей точки зрения Вам невозможно ни при каких условиях. Любые доводы и материалы Вы будете отвергать под произвольно выдуманными предлогами (причём эти субъективные предлоги будут подаваться под видом истины в последней инстанции), отвечать вопросами на вопрос (и не просто отвечать, а требовать ответа на свои вопросы в крайне грубой форме) и использовать другие некрасивые методы типа придираться к словам, а не к смыслу.

Даже не "грубо говоря", а файл и есть. В unix любые каналы, сокеты и прочее суть файлы. А также устройства (блочные и символьные), каталоги и т.д. Всё это файлы. Причём официально, а не "грубо говоря".

Вы не находите, что "Все это файлы" несколько отличается от первоначального "В оригинале, Unix построен на взаимодействии программ через текстовые файлы"?
Являются ли вообще все файлы, через которые происходит взаимодействие программ, текстовыми?
GUI vs. текстовый конфиг

Так что, не любым способом, а вполне себе скриптами.

Автор рассуждает на немного недостаточном уровне абстракции. Также как и Вы. Надо сделать ещё один шаг.
Скрипты точно также "пришлёпка сбоку", о чём сказано, например, тут. Первичен НЕ скрипт - первична сама графическая (под?)система.
Скрипт - это всего лишь _один_ из способов управлять этой системой (также как шелл в Unix - всего лишь один из способов выполнять свои задачи в системе). GUI - другой. Непосредственное обращение из программы - третий.

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

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

Давайте не будем путать то, что принято с тем, что возможно. Мы говорим о базовом подходе *nix-систем. Если не верите мне, вот вам цитата из любимого вами Vitus'а:

Каковы же составляющие интерфейса командной строки Unix, которые оказались в свое время настолько удачные, что живут уже 30 лет, и до сих пор находится немало людей, предпочитающих их разнообразным GUI?

На мой взгляд их четыре:

1. Универсальная форма представления информации — текстовый файл, понимаемый как последовательность символов, некоторые из которых имеют специальный смысл — разделяют строки(записи), поля и слова. Его командно-строчные программы выдают на экран человеку (stdout), его же ожидают в качестве ввода (stdin). Не будь этого стандарта бесполезен был бы следующий пункт

Но, но. Во-первых, он вовсе не мой любимый.
Во-вторых, Вы опять же немного невнимательны. "Каковы же составляющие интерфейса командной строки"? Видите? Речь идёт не о взаимодействии вообще любых программ, а только о CLI.

Не поверите, наверно, но показывает "Войну и мир".

Подумал. Вроде бы действительно должен показывать. Но не мешало бы проверить.

[watashiwa_daredeska]

Автор рассуждает на немного недостаточном уровне абстракции. Также как и Вы. Надо сделать ещё один шаг.
Скрипты точно также "пришлёпка сбоку", о чём сказано, например, тут. Первичен НЕ скрипт - первична сама графическая (под?)система.
Скрипт - это всего лишь _один_ из способов управлять этой системой (также как шелл в Unix - всего лишь один из способов выполнять свои задачи в системе). GUI - другой. Непосредственное обращение из программы - третий.

Тут есть одна проблема. Автоматизация может делаться пока только скриптами. Не разработаны методы достаточно удобного и гибкого программирования графическими средствами. Запись клавиатурных макросов -- не в счет, они как правило записываются в виде того же скрипта, который далее допиливается вручную. Проблема в том, что если я могу писать эти скрипты, то необходимость "автоматизировать GUI" мне тут только мешает, гораздо удобнее использовать абстракции, родные для скриптов, а не для GUI. Хотя, возможно, я рассуждаю как программист.

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

Скажем так, GUI вообще и конфигураторы в частности в их современном виде ужасны. В перспективе -- может быть и выйдет чего путное. Однако агитировать сейчас за тотальный переход на GUI-конфигураторы все равно, что в конце 19в. агитировать за перевод локомотивов с паровых двигателей на ДВС.

Вы опять же немного невнимательны. "Каковы же составляющие интерфейса командной строки"? Видите? Речь идёт не о взаимодействии вообще любых программ, а только о CLI.

А в то время других и не было. Даже полноэкранных редакторов в Unix не было, был ed, который во всю использовался скриптами. И даже полноэкранный текстовый интерфейс до некоторой степени тоже CLI, так как реализуется тоже текстом через stdin/stdout, что позволяет делать некоторые вещи "в общем виде", например copy/paste реализуется в терминале, а не в каждой программе (хотя в некоторых программах есть и собственный copy/paste), expect, screen.

Бинарные файлы и протоколы -- исключения из правил, когда идея приносилась в жертву производительности или другим насущным потребностям. Например, хранить гигантские объемы данных в текстовом виде бессмысленно: глазами не прочитать, grep/sed/awk работают на больших объемах неприемлемо медленно, да и места, например, числовые данные в бинарном виде занимают существенно меньше.

[Warderer]

Чего-то я постоянно читая вашу тему "Искусство программирования для UNIX" Эрика Реймонда вспоминаю.

[drBatty]

У вас YaST, у меня adduser.

у меня тоже ГУИ есть, но там как-то криво всё задаётся(может просто ГУИ в мандриве кривой), man adduser лично для меня намного проще. Причём я к оффтопику привык за многие годы, должно быть наоборот...

[drBatty]

Интересно у Вас как-то.... Получается что на каждую опцию написать что-то вроде: "Unknown value "1" for param SomeParam on line 204 of '/etc/some.prog.conf'. Only "yes" or "no" allowed" это несложно, а проделать то же самое в GUI религия запрещает??

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

[Ben Aceler]

Интересно у Вас как-то.... Получается что на каждую опцию написать что-то вроде: "Unknown value "1" for param SomeParam on line 204 of '/etc/some.prog.conf'. Only "yes" or "no" allowed" это несложно, а проделать то же самое в GUI религия запрещает??

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

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

[oneq]

Тут есть одна проблема. Автоматизация может делаться пока только скриптами.

Не совсем согласен. На самом деле "пока только скриптами" скорее по двум причинам:
1) Современные распространенные GUI спроектированы и реализованы на основе другого подхода. Есть, конечно, пример Мака, но ведь он не настолько распространен. Остальные распространены ещё меньше.
2) Хранить конечный результат в виде скрипта - это то же самое, что хранить конфиг в каком-либо легко редактируемом человеком и другими программами виде. На самом деле результат можно записывать в любом произвольно выбранном виде. Единственное - Вам потребуется разработать какие-то общесистемные библиотеки/утилиты для того, чтобы выполнить условие редактирования человеком и/или другими программами.

Не разработаны методы достаточно удобного и гибкого программирования графическими средствами. Запись клавиатурных макросов -- не в счет, они как правило записываются в виде того же скрипта, который далее допиливается вручную. Проблема в том, что если я могу писать эти скрипты, то необходимость "автоматизировать GUI" мне тут только мешает, гораздо удобнее использовать абстракции, родные для скриптов, а не для GUI. Хотя, возможно, я рассуждаю как программист.

Не знаю как другие, а вот в MS SQL можно запросы натурально рисовать. Причём - на вполне приемлемом уровне.
При этом условия успешного применения выполняются полностью: результат работы GUI редактора сохраняется в виде, доступном для человека и других программ (да, да, в виде всё того же plain text запроса ); сама база данных также доступна человеку и программам несмотря на то, что она очень даже не plain text - есть общесистемные библиотеки и утилиты.

Скажем так, GUI вообще и конфигураторы в частности в их современном виде ужасны. В перспективе -- может быть и выйдет чего путное. Однако агитировать сейчас за тотальный переход на GUI-конфигураторы все равно, что в конце 19в. агитировать за перевод локомотивов с паровых двигателей на ДВС.

Так я же за это и не агитирую

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

Если честно - не вижу никаких различий и почему должны быть "ВСЕ возможные сочетания галок"? Ведь галки не обязаны быть взаимозависимыми. А взаимозависимые, как я уже говорил, в GUI весьма просто делаются с нужными параметрами при выборе одной из них.
Кроме того Вы просили проще. Я привёл пример проще. В конфиге PureFTPD есть два параметра AnonymousOnly и NoAnonymous, оба работают по логике "галок", т.е. могут принимать только значения yes или no. Нужно ли авторам PureFTPD проверять этот заведомо неработоспособный вариант?

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

Вы никогда не видели программ, у которых конфигуратор отделён от самой программы?

[drBatty]

Если честно - не вижу никаких различий и почему должны быть "ВСЕ возможные сочетания галок"? Ведь галки не обязаны быть взаимозависимыми. А взаимозависимые, как я уже говорил, в GUI весьма просто делаются с нужными параметрами при выборе одной из них.

а я вижу.
и "весьма просто" зависимые галки ставятся только в пределах задачи автора. Если у меня другая задача, мне надо эти галки ставить по другому. Я не говорил что это принципиально не возможно, просто гибкости ГУИ в 99% случаях для такого не хватит, а вот гибкости конфига - вполне.

В конфиге PureFTPD есть два параметра AnonymousOnly и NoAnonymous, оба работают по логике "галок", т.е. могут принимать только значения yes или no. Нужно ли авторам PureFTPD проверять этот заведомо неработоспособный вариант?

этот - нет конечно. ИМХО в данном случае в данной программе конфиг просто недоделан.
Лично я бы сделал одну директиву:
Anonymous
с тремя значениями
yes
no
only
однако авторы поленились убрать лишнюю директиву, понадеявшись на разумность юзера.
В ГУИ такое бывает в разы чаще.

[oneq]

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

Вот есть у Вас галка "использовать syslog для ведения журнала". Дальше есть разные галки, объясняющие программе, как именно ей использовать этот самый syslog.
Логично, что при снятии галки "использовать syslog для ведения журнала" доступ ко всем остальным галкам, имеющим отношение к syslog'у, надо запретить. Как изменит поведение программы выставление этих самых галок "по другому"? Имхо - никак не изменит, пока не будет включена "использовать".

этот - нет конечно. ИМХО в данном случае в данной программе конфиг просто недоделан.

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

[watashiwa_daredeska]

1) Современные распространенные GUI спроектированы и реализованы на основе другого подхода. Есть, конечно, пример Мака, но ведь он не настолько распространен.

У Мака ровно тот же подход. Чуть более качественный и с чуть более другими фичами, но в целом ровно тот же.

Не знаю как другие, а вот в MS SQL можно запросы натурально рисовать. Причём - на вполне приемлемом уровне.
При этом условия успешного применения выполняются полностью: результат работы GUI редактора сохраняется в виде, доступном для человека и других программ (да, да, в виде всё того же plain text запроса ); сама база данных также доступна человеку и программам несмотря на то, что она очень даже не plain text - есть общесистемные библиотеки и утилиты.

Возможно. Визуальные редакторы SQL-запросов видел последний раз очень давно. Однако, как там дальше? Ведь SQL-запрос -- еще не вся программа.

Вообще, у меня складывается впечатление, что вся эта разработка "средств разработки для пользователя" -- пустая трата усилий. Проблема основной массы потребителей в том, что они не могут формализовать, что же им на самом деле надо. Когда кто-то случайно сделает то, что надо, тогда потребитель сможет ткнуть пальцем и сказать: "мне надо вот это", но что такое "это" сказать никто не может. Отсюда и проблемы с переходом с Win на Lin, отсюда и засилье 1С. На самом деле, большинство потребителей не мыслят в терминах того, ЧТО им надо сделать (будь то написание документа или сведение годового баланса), они мыслят КАК им надо делать, поэтому при изменении программы, для потребителя полностью меняется КАК без малейшего понимания ЧТО, т.е. замене подлежат пракически 100% навыков. Никакие возможности GUI-программирования не будут ими востребованы. Возможно, скоро подрастет более развитое молодое поколение, с детства тренированное усваивать бОльшее число рефлексов, но и оно вряд ли будет так уж программировать, даже в GUI.