>>>Неправда, на чистом шелле можно сделать достаточно много -- почитайте исходники
>>>http://altlinux.org/libshell или http://www.altlinux.org/control и удивитесь.
>> Покажите в Debian.
> В дебиане и этого нет, помнится.  Ссылки на git предложенного для
> чтения в качестве примера нетривиальных программ/блоков на shell устроят?

Нет. Давайте сразу ссылку на zsh, в котором ftp-клиент есть часть функциональности шелла.

>  Встречный
> вопрос -- Вы пробовали скриптовать восстановление уничтоженной таблицы разделов?  Было
> бы крайне интересно узнать про обстоятельства, сподвигнувшие на такую автоматизацию.  
> Кроме шуток.

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

>[оверквотинг удален]
> DISKS="b c d e f g h i"
> PAT="UDMA_CRC_Error_Count|Reallocated_Event_Count|Offline_Uncorrectable"
> PAT="$PAT|Current_Pending_Sector|Raw_Read_Error_Rate|Seek_Error_Rate"
> echo "querying... "
> for i in $DISKS; do smartquery $i; done | grep -v "
> 0$" | sort
> echo
> echo "temperatures... "
> for i in $DISKS; do tempquery $i; done | sort -rnk2
>

Отсутствие проверки входных параметров и анализа системы (это я про DISKS="b c d e f g h i" ). Простая фильтрация данных. Отсутствие хоть какого-то анализа полученной информации... И где автоматизация?

>> Над программой с псевдографикой не написать ничего на шелле.
> Как автор одной из mc extfs выражаю крайнее удивление.

_Над_ программой. Обёртку.

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

То-то графические программы не являются интерфейсами над консольными.

>>> Покажите в Debian.
>> В дебиане и этого нет, помнится.  Ссылки на git предложенного для
>> чтения в качестве примера нетривиальных программ/блоков на shell устроят?

Перевожу: на Ваш съезд есть что ответить. :)

> Нет. Давайте сразу ссылку на zsh, в котором ftp-клиент есть часть функциональности
> шелла.

А вот на это отвечу то, что обсуждается (ba)sh, а не произвольный korn-like shell.  Но раз так настаиваете, пожалуйста: http://www.zsh.org/

>> Вы пробовали скриптовать восстановление уничтоженной таблицы разделов?
> Автоматизировать можно получение необходимой информации

Что *можно*, понятно.  Интересует реальный опыт и выводы из него.

> Отсутствие проверки входных параметров

Где именно?

> и анализа системы (это я про DISKS="b c d e f g h i" ).

Это несложно добавить, если кому понадобится -- маякните.  Скрипт используется на одном хосте и там единственное изменение было обусловлено выносом корня на IDE CF. :)

> Простая фильтрация данных. Отсутствие хоть какого-то анализа полученной информации...

Именно это и требовалось, а анализ производится глазами (в т.ч. сравнивая с сохранённым выводом на более ранние даты).

> И где автоматизация?

В работе и реально используется.

>>> Над программой с псевдографикой не написать ничего на шелле.
>> Как автор одной из mc extfs выражаю крайнее удивление.
> _Над_ программой. Обёртку.

Тогда определите "над" и приведите примеры, пожалуйста.

> То-то графические программы не являются интерфейсами над консольными.

Смотря какие.

Постарайтесь аккуратней обобщать, меньше будет споров над _почти_ правильно сказанным.

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

Предпочитаете удобства во дворе?

> Предпочитаете удобства во дворе?

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

>> Предпочитаете удобства во дворе?
> Не вижу смысла городить макдональдс, когда нужен туалет.

Странно, что у вас существуют только такие варианты.

> Странно, что у вас существуют только такие варианты.

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

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

Нет никакого подходящего - вы даже потрудились толком объяснить, как парсить вывод smartctl в общем случае. К примеру, параметры smart у разных дисков - разные, а выводятся далеко не все.

> К примеру, параметры smart у разных дисков - разные, а выводятся далеко не все.

Лень лезть в стандарт, чтоб ткнуть носом в строчку -- но те, которые меня интересуют и зафиксированы в скрипте (ID 199, 196, 198, 197, 1, 7), наблюдаются у _всех_ HDD, которые интересовали.

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

>> К примеру, параметры smart у разных дисков - разные, а выводятся далеко не все.
> Лень лезть в стандарт, чтоб ткнуть носом в строчку -- но те,
> которые меня интересуют и зафиксированы в скрипте (ID 199, 196, 198,
> 197, 1, 7), наблюдаются у _всех_ HDD, которые интересовали.

А остальные для красоты, что ли? Меня вот интересуют 4, 9, 12, особенно в свете недавних новостей о частой парковки дисков под убунтой.

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

И это только один ключик программы. А у программы ключиков много.

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

> А остальные для красоты, что ли? Меня вот интересуют 4, 9, 12,
> особенно в свете недавних новостей о частой парковки дисков под убунтой.

В данном случае (восемь дисков вовсе не под убунтой) -- нерелевантны:
Power_Cycle_Count: 103/106/106/106/63/63/63/64
Power_On_Hours: 32893/32893/32893/32896/16144/16145/16145/16146
Start_Stop_Count: 105/108/108/108/63/63/63/64
(упорядочивание внутри рядов не проводилось)

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

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

Вы опять циклитесь на "ключиках программы".  User294 таких отправляет делать морду к ffmpeg и правильно делает: *поставленная* задача решена (достаётся и показывается ровно интересующая информация), а большего в *данном* случае и не требуется.  Будет надо -- будет сделано.

>> Надо уметь сказать "да, я был неправ/не подумал" и остановиться.

>> А остальные для красоты, что ли? Меня вот интересуют 4, 9, 12,
>> особенно в свете недавних новостей о частой парковки дисков под убунтой.
> В данном случае (восемь дисков вовсе не под убунтой) -- нерелевантны:
> Power_Cycle_Count: 103/106/106/106/63/63/63/64
> Power_On_Hours: 32893/32893/32893/32896/16144/16145/16145/16146
> Start_Stop_Count: 105/108/108/108/63/63/63/64
> (упорядочивание внутри рядов не проводилось)

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

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

Мне не интересно решение конкретно этой проблемы - у меня есть и другие. Не интересно частное решение задачи - интересно с прицелом на универсальность. И здесь нужно не в вопросы-ответы идти, а иметь документ + сообщество по проблемам пользовательского программирования под Linux.

>> И да, с пятью типами показаний чего-то делать надо, а не просто вывести.
>> И это только один ключик программы. А у программы ключиков много.
> Вы опять циклитесь на "ключиках программы".  User294 таких отправляет делать морду
> к ffmpeg и правильно делает: *поставленная* задача решена (достаётся и показывается
> ровно интересующая информация), а большего в *данном* случае и не требуется.
>  Будет надо -- будет сделано.

Задача поставлена вами, вами она и решена. Моя задача другая - получить решение проблемы в общем случае. С возможностью пользователю скриптик с решением пилить под себя. А у меня нет ни решения, ни техзадания. А поставить сам себе техзадание я не могу - я -- пользователь, и в подобных проблемах хорошо не разбираюсь. Вы же довольствуетесь кустарным решением частного случая.

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

>>> Надо уметь сказать "да, я был неправ/не подумал" и остановиться.

> Что значит "в данном случае"?

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

> и отлавливаться только предварительно готовой к подобным проблемой программой

У Вас опять продуктопоклонство.  Поясняю: опубликованный в #129 подан как пример из жизни, а не продукт на все случаи жизни.  Разницу, надеюсь, улавливаете.

> Не интересно частное решение задачи - интересно с прицелом на универсальность.

Ну-у, такую задачку тоже можно решать, но тут может быть разумней пообщаться с разработчиками той же g-d-u или поискать более подходящую софтинку.  И тоже попытаюсь в меру сил помочь, хотя тут скорее тестированием на доступных стендах.

> И здесь нужно не в вопросы-ответы идти, а иметь документ + сообщество по проблемам
> пользовательского программирования под Linux.

Кому надо -- ищет возможность, кому нет -- оправдание... здесь действительно всё просто иначе, чем MSDN+rsdn.  Чем-то хуже, чем-то лучше.  Мне так однозначно лучше.

> Задача поставлена вами, вами она и решена.

Фух :-)

> Моя задача другая - получить решение проблемы в общем случае.

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

> А поставить сам себе техзадание я не могу - я -- пользователь, и в подобных проблемах
> хорошо не разбираюсь.

Эх.

> Вы же довольствуетесь кустарным решением частного случая.

Ну да, а на большее оно и не претендует.  Дело в другом -- такой скриптик набрасывается гораздо быстрее, чем половина этого субтреда, и просто работает.  Если понадобится мониторить разницу и слать её почтой при превышении порога -- это ещё минут пять, ну десять.  Хотя в процессе можно стукнуть кулаком и сказать "так, пора прикрутить zabbix". :)

Благодарю за понимание и прошу прощения за резкие порой слова.

>> Что значит "в данном случае"?
> То и значит, что Ваш умеренно покорный слуга предпочитает сразу покупать подходящие
> диски, чем героически решать привнесённые производителем "зелёных" серий проблемы на ровном
> месте.

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

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

Это windows-way, знаете ли. Столлман любит пародировать такие молитвы разработчикам.

>> И здесь нужно не в вопросы-ответы идти, а иметь документ + сообщество по проблемам
>> пользовательского программирования под Linux.
> Кому надо -- ищет возможность, кому нет -- оправдание...

Бинарная логика здесь не действует: между этими крайними случаями существует куча других.

> здесь действительно всё
> просто иначе, чем MSDN+rsdn.  Чем-то хуже, чем-то лучше.  Мне
> так однозначно лучше.

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

> Те же MS загибают пользователя
> в выбранный собственноручно весьма частный случай обычно (а те же Apple
> так ещё жёстче).  

А у них система не на скриптовом языке.

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

Дорабатываться он будет много сложнее. А готовый и (почти) универсальный - много проще.

>  Если понадобится мониторить разницу и слать её
> почтой при превышении порога -- это ещё минут пять, ну десять.

А оптимальный порог вы как собираетесь определять? Это, знаете ли, обработка данных не одной тысячи пользователей, у которых есть данные smart за достаточно длительный период, после которого диск накрылся.

У обычного пользователя нет восьми дисков. Потеря одного - уже катастрофа. Он не помнит, в каких скриптах он написал DISKS = a b, чтобы это исправить при добавлении/извлечении/смене дисков, ибо он не админ с правильным стилем работы, и админные работы очень редки, чтобы помнить всё, что пришлось менять.  Ну и т. д. Всё это при написании скрипта невозможно учесть обычному юзеру. То есть, ещё раз про правильно поставленное техзадание. Так что, увы, готовый скрипт с богатыми настройками такого плана предпочтительнее написание своего с нуля.

> Благодарю за понимание и прошу прощения за резкие порой слова.

> Вообще-то речь была про проблемы в софте. И они, эти проблемы, потенциально
> везде могут возникнуть, а не только в самих дисках.

Ну так не юзайте такой софт, где они сыплются на голову без приглашения.

>>> Не интересно частное решение задачи - интересно с прицелом на универсальность.
>> Ну-у, такую задачку тоже можно решать, но тут может быть разумней пообщаться
>> с разработчиками той же g-d-u или поискать более подходящую софтинку.
> Это windows-way, знаете ли.

Стоп.

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

Я свою хотелку вполне юниксвейно удовлетворил ещё зимой 2009.

> Столлман любит пародировать такие молитвы разработчикам.

На этом месте мне, наверное, полагается приплести не в тему Балмера.  Зачем бы?..

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

Если готовый набор есть и таскать тикль устраивает -- почему бы и нет.

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

Вот только мне это не рассказывайте, ладно? :)

> А готовый и (почти) универсальный - много проще.

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

>> Если понадобится мониторить разницу и слать её почтой при превышении порога
> А оптимальный порог вы как собираетесь определять?

Эмпирически.

> Это, знаете ли, обработка данных не одной тысячи пользователей

До них нет дела (скриптик-то для себя, другим предоставляется as is).  А если будет -- организую, тоже мне бином Ньютона.

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

> Ну так не юзайте такой софт, где они сыплются на голову без
> приглашения.

Хорошо, буду спрашивать у софта перед использованием, есть в нём такого рода ошибки или нет.

>>>> Не интересно частное решение задачи - интересно с прицелом на универсальность.
>>> Ну-у, такую задачку тоже можно решать, но тут может быть разумней пообщаться
>>> с разработчиками той же g-d-u или поискать более подходящую софтинку.
>> Это windows-way, знаете ли.
> Стоп.
> Вы хотели универсальную софтинку?  Тогда выбирайте -- основываться на чём-то либо
> писать с нуля.  Если основываться -- это вопрос выбора проекта
> и налаживания взаимодействия.  Если с нуля -- хозяин-барин.

Доработка программы на скриптовом языке. Или: написание скриптовой логики при наличии библиотек. Казалось бы, это возможно при наличии бинарных программ (куда пользователю лезть не нужно) и скриптовых языков. Ан нет, пишут логику и GUI тоже на C почему-то.

Я, к примеру, очень надеюсь (и жду) на пайтон и его богатые либки. Хотя тикль поприятнее, конечно.

> Я свою хотелку вполне юниксвейно удовлетворил ещё зимой 2009.

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

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

А готовый набор - не некий аналог MSDN? Или вас реализация не устраивает?

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

Я про пользователя.

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

Но создавать-то его, а, главное, тестировать, будет не один человек.

>>> Если понадобится мониторить разницу и слать её почтой при превышении порога
>> А оптимальный порог вы как собираетесь определять?
> Эмпирически.

Всмысле, на собственных ошибках (в данном случае, ошибках дисков)? Или пальцем в небо?

>> Это, знаете ли, обработка данных не одной тысячи пользователей
> До них нет дела (скриптик-то для себя, другим предоставляется as is).  
> другим предоставляется as is

Вот и открывается тёмная сторона системной автоматизации на bash: as is, до них нет дела, самобытные скрипты, кустарщина, куча повторной работы, высокая квалификация ( дописать проще, чем писать с нуля) ну и т. д.

> На юниксах проще делать подножную автоматизацию и попросту нет такой необходимости в
> продухтах на каждый чих вроде "скопировать диск на другой диск байт-в-байт".

Подножная автоматизация - это как подножный корм - когда есть нечего, но что-то надо?

> У вас просто очень простые хотелки.

Вот потому и безотказные.

>>> Дорабатываться он будет много сложнее.
>> Вот только мне это не рассказывайте, ладно? :)
> Я про пользователя.

Я и есть пользователь.

>>> А оптимальный порог вы как собираетесь определять?
>> Эмпирически.
> Всмысле, на собственных ошибках (в данном случае, ошибках дисков)?

Именно что не моих, а дисков.  С учётом количества уже определённых на замену и использования RAID1/10+бэкапов для всего уникального меня данная мерка устраивает.

> Вот и открывается тёмная сторона системной автоматизации на bash: as is

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

> Подножная автоматизация - это как подножный корм - когда есть нечего, но
> что-то надо?

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

> Вам сюда: http://stackoverflow.com/questions/928019/how-to-make-a-gui-...
> (можно предложить и другие примеры, просто это "над ней" немножко лишено
> смысла, по крайней мере не удалось обнаружить).

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

gtkserver?

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

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

ну дык это… где ближайший склад напильников — в курсе? %-)

> графический интерфейс - это, скажем, вывод браузера, прочитавшего html-документ.

Вам страничку шелловым CGI выдать?

> А диалоги - это фигня, а не интерфейс, тем более графический.

Похоже, разговор теряет остатки смысла... может, Раскина сперва почитаете, или тоже сразу учить будете? :)

>может, Раскина сперва почитаете, или тоже сразу
> учить будете? :)

Всмысле? Раскин изучал, как удобно пользователю, а не указывал. Если пользователю неудобен интерфейс, то Раскин не указ.

а говорят, arisu тролль.

>> Какова альтернатива среди скриптовых языков?
> (Ba)sh - для системной автоматизации.

Для очень кустарной автоматизации - да. Ну или для любителей парсить естественный язык регекспами.

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

Его уже почти выбросили, судя по составу хранилищ.

>Для приложений - си/си++.

А для пользовательского программирования? Ну, в случае импотенции программистов, но необходимости иметь программу?

>>>Ну и значок в трее жрущий 20М памяти на просто сам факт своего существования
>> FF и OO просто за факт существования больше берут.
> FF и OO - мощные программы умеющие дофига всего.

Когда они начинают уметь дофига всего, они и в память могут не уложиться.

>> А если JS в первом включить...
> Кстатие если уж о JS вспомнили, там хотя-бы JIT есть.

Который увеличивает скорость, а не потребление памяти. А сохранение памяти - бо'льшая проблема.

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

А теперь докажите.  Берусь спорить не подглядывая в ftp.linux.kiev.ua, что в *любом* представленном там линуксовом репозитории пакет (или в эквиваленте) bash/sh найдётся.

>>> (Ba)sh - для системной автоматизации.
>>>Его выбросить не получится, да и делался как раз для этого.
>> Его уже почти выбросили, судя по составу хранилищ.
> А теперь докажите.  

Perl.

>>>> (Ba)sh - для системной автоматизации.
>>>>Его выбросить не получится, да и делался как раз для этого.
>>> Его уже почти выбросили, судя по составу хранилищ.
>> А теперь докажите.
> Perl.

Мимо.

>>>>> (Ba)sh - для системной автоматизации.
>>>>>Его выбросить не получится, да и делался как раз для этого.
>>>> Его уже почти выбросили, судя по составу хранилищ.
>>> А теперь докажите.
>> Perl.
> Мимо.

Выбросили из системной автоматизации, а не из уже работающей инфраструктуры. Выбросили бы и из второй, да лень людям, видимо.

>>>>>> (Ba)sh - для системной автоматизации.
>>>>>>Его выбросить не получится, да и делался как раз для этого.
>>>>> Его уже почти выбросили, судя по составу хранилищ.
>>>> А теперь докажите.
>>> Perl.
>> Мимо.
> Выбросили из системной автоматизации

Домашнее задание:

find /usr/bin -perm -111 | xargs file -b | grep '^Bourne shell script' | wc -l

> Домашнее задание:
> find /usr/bin -perm -111 | xargs file -b | grep '^Bourne shell
> script' | wc -l

apt-cache rdepends bash|wc -l
87

apt-cache rdepends perl|grep -v lib|wc -l
1653

>> find /usr/bin
> apt-cache

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

PS: поменял местами К и П, конечно же.

>>> find /usr/bin
>> apt-cache
> Опять путаете кинетическое с потенциальным.  На перле можно гораздо больше написать
> -- и, наверное, гораздо больше написано (реюзабельного так точно).  Но
> это не умаляет роли шелла, поймите.
> PS: поменял местами К и П, конечно же.

А я и не умоляю роль шелла - обеспечение работы написанной инфраструктуры. +, может быть, удобный запуск программ. Для автоматизации, настоящей, не годится. И причины внешние, в основном. Не регулярная грамматика у вывода многих программ. И полноценного разбора/анализа нет и быть не может.

Похоже вы просто не писали толком на шелле.

export LANG="C"
blablabla

и 99.9% внешних программ вернут заведомо известный контент с которым вполне можно работать в случае если программа не поддерживает форматирование вывода сама(такие как stat, date..).

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

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

Вобщем при всей простоте шелла он является гибким и мощным инструментом. Он всегда есть искаробки. И использование любого другого скриптового языка(Perl, Python) зачастую бывает неоправданным.

> Похоже вы просто не писали толком на шелле.

И мало кто пишет толком.

> export LANG="C"
> blablabla
> и 99.9% внешних программ вернут заведомо известный контент с которым вполне можно
> работать в случае если программа не поддерживает форматирование вывода сама(такие как
> stat, date..).

ps. Стандартная, казалось бы, команда. И комментарий в tkps:

################################################################
# This runs ps with the (optional) user command line args.
# It fills the listbox with a list of all the processes running,
# using the ps output.
#
# How do we locate the PID of a process?
#
# We then look through the keyword (header) list to see if we find the PID
# column, and remember which column that is, so we can operate on selected
# processes. Yeesh. After we do 'split' on each line of output, we need
# to eliminate the multiple blanks, and we still are hoping that ps
# doesn't insert a blank between two words in a column. There is no
# direct portable system call which gives basic process information about
# all processes on a machine. There is just 'ps', and we are parsing the
# random text output of a stupid utility program.
#
# Argh. unix sucks.

ты ещё configure сюда процитируй.

> А я и не умоляю роль шелла

Она неумолима (а "умалять" -- это "представлять более малой, чем в действительности").

> Для автоматизации, настоящей, не годится.

Определите "настоящесть".

Не годится для работы со сложными и объёмными структурами данных средствами шелла.  При этом прекрасно (местами лучше того же перла) годится для _организации_ потокового взаимодействия между программами, продуманными с учётом взаимодействия.  Например, в том же Daylight есть крайне хорошо продуманные утилиты выборки из иерархической базы данных, которые могут по надобности либо всю запись представить одной строкой, либо каждый "листик" отдельно.  Работать с такой БД обычными grep/sed было весьма непривычно, но на удивление удобно :)

> И причины внешние, в основном. Не регулярная грамматика у вывода многих программ.

Главное -- чтоб стабильный формат поддерживался.

> И полноценного разбора/анализа нет и быть не может.

Может, просто не всегда удобно.

То есть Вы опять почти правду пишете, но сгущаете краски и трагедизируете совсем зря.  На практике -- ужас, но не ужас-ужас-ужас ;-)

>> А я и не умоляю роль шелла
> Она неумолима (а "умалять" -- это "представлять более малой, чем в действительности").

Спасибо, КЭП.

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

Формат на стабильность проверяется наличием описания грамматики, а не разбросанными но всему ману описаниями его, формата, частей.

>> И полноценного разбора/анализа нет и быть не может.
> Может, просто не всегда удобно.
> То есть Вы опять почти правду пишете, но сгущаете краски и трагедизируете
> совсем зря.  На практике -- ужас, но не ужас-ужас-ужас ;-)

Ну если over 9000 программ, написанных не в стиле Unix-way - бинарные  компоненты объединяются скриптовым языком - это не ужас-ужас-ужас, то извините. Кустарщина не в счёт.

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

То есть грамматика плавать не может, а если и может, то мы об этом не слышали.  Ладно...

> Ну если over 9000 программ, написанных не в стиле Unix-way - бинарные
> компоненты объединяются скриптовым языком - это не ужас-ужас-ужас, то извините.

Не, не ужас-ужас-ужас.  Максимум ужас.  За триллерами приходится на винду всё-таки в гости ходить.

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

Грамматика плавать может, к примеру, как только появляется естественный язык, не имеющий машинно-ориентированной альтернативы. Которую предлагают парсить через export LANG="C", забывая, что сообщения запросто могут исправить, и скрипт сломается.

>> Ну если over 9000 программ, написанных не в стиле Unix-way - бинарные
>> компоненты объединяются скриптовым языком - это не ужас-ужас-ужас, то извините.
> Не, не ужас-ужас-ужас.  Максимум ужас.  За триллерами приходится на винду
> всё-таки в гости ходить.

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

> Грамматика плавать может, к примеру, как только появляется естественный язык,
> не имеющий машинно-ориентированной альтернативы.

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

> Которую предлагают парсить через export LANG="C", забывая, что сообщения
> запросто могут исправить, и скрипт сломается.

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

> На винде есть работающие программы для тривиальных случаев

Для тривиальных случаев и gnome-disk-utility сгодится.

> А не тупая фильтрация части информации с надеждой, что ничего важного не упущено.

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

> И на
> практике такое плавание -- далеко не такая распространённая и крупная проблема,
> как пытаетесь представить.  Это три.

Зато первая по воплям "караул, сломался скрипт". И первая, ведущая к ни черта не умеющим скриптам.

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

Уважаемый, стабильный формат без документации - не формат. Документации на синтаксис, а не на возможный состав вывода для чтения человеком.

>> На винде есть работающие программы для тривиальных случаев
> Для тривиальных случаев и gnome-disk-utility сгодится.

Интересная штука. Но про скриптование можно забыть.  А оно здесь необходимо - окна на 2 экрана в ширину и горизонтальный скроллинг.

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

Судя по KDE 4 и GNOME 3, китайцы  с индусами не только в винде работают.

>> И на практике такое плавание -- далеко не такая распространённая и крупная проблема,
>> как пытаетесь представить.  Это три.
> Зато первая по воплям "караул, сломался скрипт".

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

> И первая, ведущая к ни черта не умеющим скриптам.

Похоже, случай всё-таки клинический.

> Уважаемый, стабильный формат без документации - не формат. Документации на синтаксис,
> а не на возможный состав вывода для чтения человеком.

Любезнейший, нередко (хоть и не всегда) нужный формат можно нарисовать себе самому, пользуясь документированными подстановками.  Гляньте date(1) для примера, что ли, а то чушь уже запороли до полусмерти.

> Интересная штука. Но про скриптование можно забыть.  А оно здесь необходимо

Зачем именно?

> Судя по KDE 4 и GNOME 3, китайцы  с индусами не только в винде работают.

http://www.opennet.me/openforum/vsluhforumID3/86051.html#37 ;-)

> Отнюдь.  Чаще ломаются небрежно написанные скрипты, огрёбшие неожиданный ввод

Изменение  формата вывода - и есть неожиданный ввод.

> или запущенные
> в непредвиденной автором среде.

Изменение формата вывода - и есть частный случай такого.

>> Уважаемый, стабильный формат без документации - не формат. Документации на синтаксис,
>> а не на возможный состав вывода для чтения человеком.
> Любезнейший, нередко (хоть и не всегда) нужный формат можно нарисовать себе самому,
> пользуясь документированными подстановками.  Гляньте date(1) для примера, что ли, а
> то чушь уже запороли до полусмерти.

Чего сразу не yes(1)? Подбирать инструменты под часть требований - это у вас хорошо выходит.

>> Интересная штука. Но про скриптование можно забыть.  А оно здесь необходимо
> Зачем именно?

А в исходном сообщении написано - интерфейс хреновый. Впрочем, зачем скриптование в системе, предназначенной для скриптования - глупый вопрос by design.

>> Судя по KDE 4 и GNOME 3, китайцы  с индусами не только в винде работают.
> http://www.opennet.me/openforum/vsluhforumID3/86051.html#37 ;-)

Да, использования хорошо протестированного старья спасает некоторую часть из 1 %. Только вот ещё есть FF, OO и Ко.

>> Отнюдь.  Чаще ломаются небрежно написанные скрипты, огрёбшие неожиданный ввод
> Изменение  формата вывода - и есть неожиданный ввод.

Хорошо.  "Чаще всего ломаются небрежно написанные скрипты, огрёбшие неожиданный ввод, не являющийся следствием изменения формата вывода используемых утилит".

>> или запущенные в непредвиденной автором среде.
> Изменение формата вывода - и есть частный случай такого.

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

> Чего сразу не yes(1)? Подбирать инструменты под часть требований -
> это у вас хорошо выходит.

Когда нужен yes(1), беру yes(1).  Да и вообще на мои скрипты их пользователи редко жалуются, просто инструменты действительно стоит подбирать под задачу.  Иногда приходится их дорабатывать или писать заново, c'est la vie.

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

Я не понял, что в "горизонтально скролящемся интерфейсе" можно улучшить его скриптованием, а не доработкой формы.  Можно для тормозящих план подробнее объяснить?  Допустим, что нечто скриптуется.  Дальше что?

> Впрочем, зачем скриптование в системе, предназначенной для скриптования -
> глупый вопрос by design.

Что-то таких систем сходу не припомню: обычно они всё-таки предназначаются для решения более реальных задач, чем станки ради станков.  Впрочем, не настаиваю, мистер design.

>> http://www.opennet.me/openforum/vsluhforumID3/86051.html#37 ;-)
> Да, использования хорошо протестированного старья спасает некоторую часть из 1 %.

Так определитесь наконец -- 1%, 2% или сколько там по Геббельсу?  И хватит уже завидовать, на винду кто-то тоже LiteStep относил (хотя не знаю, живёт ли на нынешних).

> Только вот ещё есть FF, OO и Ко.

Пишу из firefox 14, полёт нормальный.

> Хорошо.  "Чаще всего ломаются небрежно написанные скрипты, огрёбшие неожиданный ввод, не
> являющийся следствием изменения формата вывода используемых утилит".

А что ещё, кроме пользовательского ввода?

>>> или запущенные в непредвиденной автором среде.
>> Изменение формата вывода - и есть частный случай такого.
> Согласен.  "Или запущенные в непредвиденной автором среде, не учитывая последствия изменений
> формата вывода используемых утилит, за исключением локалезависимых изменений".

Локалезависимые изменения - это переменные окружения, что-ли?

>> Чего сразу не yes(1)? Подбирать инструменты под часть требований -
>> это у вас хорошо выходит.
> Когда нужен yes(1), беру yes(1).  Да и вообще на мои скрипты
> их пользователи редко жалуются, просто инструменты действительно стоит подбирать под задачу.
>  Иногда приходится их дорабатывать или писать заново, c'est la vie.

Простые пользователи вообще редко правильно жалуются разработчикам. Иначе такой бы рай в багтракере наступил. А вот когда пользователи чуть подрастают, жалобы могут и появиться. Но для этого должны появиться пользователи.

И да, вы про пользователей альта? Это какой же процент от одного процента?

> Я не понял, что в "горизонтально скролящемся интерфейсе" можно улучшить его скриптованием,
> а не доработкой формы.  

Это на C, что ли?

> Можно для тормозящих план подробнее объяснить?
>  Допустим, что нечто скриптуется.  Дальше что?

Как, например, на том же Tcl интерфейс переделать при наличии нужного package? В этом вопрос?

> Что-то таких систем сходу не припомню: обычно они всё-таки предназначаются для решения
> более реальных задач, чем станки ради станков.  Впрочем, не настаиваю,
> мистер design.

Не буквоедствуйте.

>>> http://www.opennet.me/openforum/vsluhforumID3/86051.html#37 ;-)
>> Да, использования хорошо протестированного старья спасает некоторую часть из 1 %.
> Так определитесь наконец -- 1%, 2% или сколько там по Геббельсу?  

Не принципиально.

> И хватит уже завидовать, на винду кто-то тоже LiteStep относил (хотя
> не знаю, живёт ли на нынешних).

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

>> Только вот ещё есть FF, OO и Ко.
> Пишу из firefox 14, полёт нормальный.

Ну вот, а то "китайцы", "индусы"...

> А что ещё, кроме пользовательского ввода?

Остальное IMHO идёт с большим отрывом.

> Локалезависимые изменения - это переменные окружения, что-ли?

Это см. locale(1) -- т.е. да, но речь о конкретном подмножестве и это было обобщение уже сказанного другим человеком.

>> Иногда приходится их дорабатывать или писать заново, c'est la vie.
> Простые пользователи вообще редко правильно жалуются разработчикам.

Да мы и вообще порой бухтим, брюзжим, но даже письмо не напишем...

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

Да, конечно.

> И да, вы про пользователей альта? Это какой же процент от одного процента?

Некоторые мои поделия используются миллионами людей, если не больше.  Ваши-то как? ;-)

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

В случае g-d-u -- да.

>> Можно для тормозящих план подробнее объяснить?
>> Допустим, что нечто скриптуется.  Дальше что?
> Как, например, на том же Tcl интерфейс переделать при наличии нужного package?
> В этом вопрос?

Tcl/Tk (если Вы про Tk) -- совсем другой коленкор.  Точно так же Вы можете противопоставить его и написанному на плюсах с гвоздями интерфейсу поверх win32/MFC какого.  Тикль же, зараза, динамический.  И тикей к нему в этом плане хорошо притёрт.  За что и любим :)

>> Впрочем, не настаиваю, мистер design.
> Не буквоедствуйте.

Кто с троллингом придёт, тот в меню и попадёт.

>> Так определитесь наконец -- 1%, 2% или сколько там по Геббельсу?
> Непринципиально.

Ну как же, а погрешность измерений в 50--100% Вас ничуть не беспокоит? :)  Эх, поколение.

>>> Только вот ещё есть FF, OO и Ко.
>> Пишу из firefox 14, полёт нормальный.
> Ну вот, а то "китайцы", "индусы"...

Так то firefox, а то smartcheck.sh.

>> А что ещё, кроме пользовательского ввода?
> Остальное IMHO идёт с большим отрывом.

Пользовательский ввод - проблема во всех программах. И он решается частично наличием готового специализированного под формат ввода парсера. В пайтоновских программах я такие видел, в шелловских - нет.

>> Локалезависимые изменения - это переменные окружения, что-ли?
> Это см. locale(1) -- т.е. да, но речь о конкретном подмножестве и
> это было обобщение уже сказанного другим человеком.

Формат описания переменных поменялся ;) То есть нет кроссплатформенного списка возможных переменных. Мне, кстати, не удалось и просто списка используемых переменных в системе найти.

>>> Иногда приходится их дорабатывать или писать заново, c'est la vie.
>> Простые пользователи вообще редко правильно жалуются разработчикам.
> Да они и вообще порой бухтят, брюзжат, но даже письмо не напишут...

fixed.

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

Ну так ими и похвастайтесь, авось на них действительно стоит взглянуть.

>>> Я не понял, что в "горизонтально скролящемся интерфейсе" можно улучшить его
>>> скриптованием, а не доработкой формы.
>> Это на C, что ли?
> В случае g-d-u -- да.

То есть, вы пользователю в C лезть предлагаете? В системе, в которой для них специально язык создан?

>>> Можно для тормозящих план подробнее объяснить?
>>> Допустим, что нечто скриптуется.  Дальше что?
>> Как, например, на том же Tcl интерфейс переделать при наличии нужного package?
>> В этом вопрос?
> Tcl/Tk (если Вы про Tk) -- совсем другой коленкор.  Точно так
> же Вы можете противопоставить его и написанному на плюсах с гвоздями
> интерфейсу поверх win32/MFC какого.  Тикль же, зараза, динамический.  И
> тикей к нему в этом плане хорошо притёрт.  За что
> и любим :)

То есть претензий к package require smartctl (если бы была) с дальнейшим интерфейсом на тикле нет?

>>> Впрочем, не настаиваю, мистер design.
>> Не буквоедствуйте.
> Кто с троллингом придёт, тот в меню и попадёт.

Не кормите.

>>> Так определитесь наконец -- 1%, 2% или сколько там по Геббельсу?
>> Непринципиально.
> Ну как же, а погрешность измерений в 50--100% Вас ничуть не беспокоит?
> :)  Эх, поколение.

Так значение - само как погрешность. Или флуктуация.

>>>> Только вот ещё есть FF, OO и Ко.
>>> Пишу из firefox 14, полёт нормальный.
>> Ну вот, а то "китайцы", "индусы"...
> Так то firefox, а то smartcheck.sh.

В том и дело - наворотить в виндовой smartGUI много сложнее, чем в 30 МБ браузере. Да ещё и с расширениями, некоторые их которых необходимы. А smartcheck.sh нормальной программе не ровня.

> Пользовательский ввод - проблема во всех программах. И он решается частично наличием
> готового специализированного под формат ввода парсера. В пайтоновских программах
> я такие видел, в шелловских - нет.

В смысле не видели, чтоб шелловые скрипты форматировали свой вывод под дальнейший разбор?  Посмотрите при желании alterator -- правда, его тоже нет в дебиане, но гиты могу предложить (или вот: http://www.altlinux.org/Alterator/module/backend).  Там шелловые (или perl, ruby, scheme...) бэкенды, работающие аналогично FastCGI со схемовым движком.  Это что под руку сразу попалось :-)

> Формат описания переменных поменялся ;)

Хде?! :)

> То есть нет кроссплатформенного списка возможных переменных. Мне, кстати, не удалось
> и просто списка используемых переменных в системе найти.

Так он и не фиксирован.  Если моей софтинке угодно обратить внимание на значение переменной ABC_XYZ -- значит, и она может оказаться используемой.  Просто есть набор переменных, смысл которых описан в POSIX/SUS и пытаться его "перебить" может быть чревато.

> авось на них действительно стоит взглянуть.

"сало -- воно й е сало", ничего умного: https://github.com/MidnightCommander/mc/blob/4bfa6810696c8b0...

Заглянул в Advantage Database Server (Sybase выпускает для застрявших на dbf), там явно до сих пор переработанный и в процессе ухудшенный, но потомок моего инитскрипта 2001 года:
http://fly.osdn.org.ua/~mike/works/misc/ads
http://fly.osdn.org.ua/~mike/works/misc/adsscript
-- спасибо, что спросили: вот, нашёл и написал им насчёт того, что копирайт хорошо бы вернуть на место и обработку pid-файла -- тоже.

Если пройтись по пакетам на предмет заапстримленного -- наверное, ещё чего-нить накапает, не считал.

> То есть, вы пользователю в C лезть предлагаете? В системе, в которой
> для них специально язык создан?

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

> То есть претензий к package require smartctl (если бы была)

Если бы было, тогда бы и было о чём говорить.

> с дальнейшим интерфейсом на тикле нет?

Если бы этот интерфейс (видимо, всё-таки на тикее) исполнял свои задачи -- ну, хорошо.

Собственно, претензий по умолчанию и нет.

>> Ну как же, а погрешность измерений в 50--100% Вас ничуть не беспокоит? :)
> Так значение - само как погрешность. Или флуктуация.

Катализатора бывает достаточно и сотой доли процента.

> В том и дело - наворотить в виндовой smartGUI много сложнее, чем в 30 МБ браузере.

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

> А smartcheck.sh нормальной программе не ровня.

Действительно, куда уж там -- оно хотя бы работает. :)

>> Пользовательский ввод - проблема во всех программах. И он решается частично наличием
>> готового специализированного под формат ввода парсера. В пайтоновских программах
>> я такие видел, в шелловских - нет.
> В смысле не видели, чтоб шелловые скрипты форматировали свой вывод под дальнейший
> разбор?  

Не видел, чтобы разбирали пользовательский ввод с помощью готовых парсеров. То есть форматирование вроде getopt может и  видел, а остальное пытаются делать на sed/awk.

>> Формат описания переменных поменялся ;)
> Хде?! :)

В смысле состава. То есть лексем.

>> То есть нет кроссплатформенного списка возможных переменных. Мне, кстати, не удалось
>> и просто списка используемых переменных в системе найти.
> Так он и не фиксирован.  Если моей софтинке угодно обратить внимание
> на значение переменной ABC_XYZ -- значит, и она может оказаться используемой.
>  Просто есть набор переменных, смысл которых описан в POSIX/SUS и
> пытаться его "перебить" может быть чревато.

Дело не в фиксации, а в наличии списка переменных, которые в принципе могут быть использованы. Как в ЯП и стандартных глобальных переменных.

>> авось на них действительно стоит взглянуть.
> "сало -- воно й е сало", ничего умного: https://github.com/MidnightCommander/mc/blob/4bfa6810696c8b0...
> Заглянул в Advantage Database Server (Sybase выпускает для застрявших на dbf), там
> явно до сих пор переработанный и в процессе ухудшенный, но потомок
> моего инитскрипта 2001 года:
> http://fly.osdn.org.ua/~mike/works/misc/ads
> http://fly.osdn.org.ua/~mike/works/misc/adsscript
> -- спасибо, что спросили: вот, нашёл и написал им насчёт того, что
> копирайт хорошо бы вернуть на место и обработку pid-файла -- тоже.

Этим правда пользуются миллионы? Всмысле, у данных программ - миллионы пользователей?

> Если пройтись по пакетам на предмет заапстримленного -- наверное, ещё чего-нить накапает,
> не считал.
>> То есть, вы пользователю в C лезть предлагаете? В системе, в которой
>> для них специально язык создан?
> Язык C специально создан для разработки и доработки программ на C, как
> это ни удивительно.  И не будучи профессиональным программистом на нём
> даже близко -- как юзер порой вздыхаю и лезу в сишный
> софт с напильником, когда что-то надо.  А что?

То есть вы считаете, что непрофессионалу лезть в С и править гуишный код - нормально? Нет, в C, в принципе, может и пользователь залезть, подправить сообщение, там. Или даже добавить gettext. Но писать GUI - это нормально?

>> То есть претензий к package require smartctl (если бы была)
> Если бы было, тогда бы и было о чём говорить.
>> с дальнейшим интерфейсом на тикле нет?
> Если бы от интерфейс (видимо, всё-таки на тикее) исполнял свои задачи --
> ну, хорошо.
> Собственно, претензий по умолчанию и нет.

Уже хорошо. Уже в чём-то мнения сошлись.

>>> Ну как же, а погрешность измерений в 50--100% Вас ничуть не беспокоит? :)
>> Так значение - само как погрешность. Или флуктуация.
> Катализатора бывает достаточно и сотой доли процента.

Катализатор ускоряет превращение одного вещества в другое, а не в себя. И да, он ускоряет реакцию, а не смещает равновесие. Механизм тоже непонятен - как необходимость программирования на С может что-то увеличить - на ингибитор больше похоже.

>> В том и дело - наворотить в виндовой smartGUI много сложнее, чем в 30 МБ браузере.
> А это не одномерное сравнение по объёму кода: одна из программ должна
> работать с повышенными привилегиями и аппаратным обеспечением, другая -- "всего лишь"
> с сетью.

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

>> А smartcheck.sh нормальной программе не ровня.
> Действительно, куда уж там -- оно хотя бы работает. :)

> Не видел, чтобы разбирали пользовательский ввод с помощью готовых парсеров.

См., например, shell-cmdline, shell-config, shell-ini-config, shell-ip-address из комплекта libshell.  Это узкие общие случаи (если можно так выразиться), но довольно полезные.

>>> Формат описания переменных поменялся ;)
>> Хде?! :)
> В смысле состава. То есть лексем.

Так где поменялся-то, можно пример для тугодумов?

> Дело не в фиксации, а в наличии списка переменных, которые в принципе
> могут быть использованы. Как в ЯП и стандартных глобальных переменных.

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

> Этим правда пользуются миллионы? Всмысле, у данных программ - миллионы пользователей?

Строго говоря, счётчик не ставил, поэтому высказал предположение; спасибо, стоило его так и назвать.  По Sybase можно спросить одного друга, вдруг получится получить оценку изнутри компании -- но в общем-то сделанная достаточно скромна.

> То есть вы считаете, что непрофессионалу лезть в С и править гуишный код - нормально?

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

> Уже хорошо. Уже в чём-то мнения сошлись.

А у меня нет намерения спорить во что бы то ни стало :-)  Наоборот -- радуюсь, когда находится с чем согласиться.

> Катализатор ускоряет превращение одного вещества в другое, а не в себя.

Почитайте про автокаталитические реакции.

> И да, он ускоряет реакцию, а не смещает равновесие.

Именно.  Дело и есть в том, что нынешняя точка является далеко не равновесной.

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

Необходимость не может, а вот возможность -- вполне.

> С повышенными привилегиями, если я правильно ошибаюсь, должна работать очень небольшая
> часть кода, та, что работает непосредственно с железом.

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

> А логике и интерфейсу достаточно пользовательских прав.
> А в никсах да, права передаются всей программе.

Чего?!

> Ведь у вас скрипт под рутом запускается, так?

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

>> Не видел, чтобы разбирали пользовательский ввод с помощью готовых парсеров.
> См., например, shell-cmdline, shell-config, shell-ini-config, shell-ip-address из комплекта
> libshell.  Это узкие общие случаи (если можно так выразиться), но
> довольно полезные.

Спасибо, конечно, но я ведь про общий случай. Хотя, точнее, про Debian'овский. Я понимаю, что такое сделать можно и где-то делают, но тогда уточняйте : конкретно у нас, в альте, мы делаем из шелла в плане системной автоматизации то, что недоделали толком нигде.

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

>>>> Формат описания переменных поменялся ;)
>>> Хде?! :)
>> В смысле состава. То есть лексем.
> Так где поменялся-то, можно пример для тугодумов?

Скажем, значение локалей.  Это если их обрабатывать надо, а не просто тупо в C делать.

Со списком переменных окружения, которые могут делать и прикладные программы, ещё хуже.

>> Этим правда пользуются миллионы? Всмысле, у данных программ - миллионы пользователей?
> Строго говоря, счётчик не ставил, поэтому высказал предположение; спасибо, стоило его так
> и назвать.  По Sybase можно спросить одного друга, вдруг получится
> получить оценку изнутри компании -- но в общем-то сделанная достаточно скромна.

Да, спросите. По поводу пользователей, а не админов.

>> То есть вы считаете, что непрофессионалу лезть в С и править гуишный код - нормально?
> Если непрофессионалу не получается припахать профессионала и сильно нужно -- то да,
> нормально.  В процессе учиться.  И в плюсовый GUI доводилось
> с рашпилем ходить (причём под ответственность) -- ничего, пока жив.

Мне ваше мнение понятно.

>> Уже хорошо. Уже в чём-то мнения сошлись.
> А у меня нет намерения спорить во что бы то ни стало
> :-)  Наоборот -- радуюсь, когда находится с чем согласиться.

Так мнения сошлись в том, в чём раньше расходились. Причём моё мнение осталось неизменным.

>> Катализатор ускоряет превращение одного вещества в другое, а не в себя.
> Почитайте про автокаталитические реакции.

В них катализатор - один из продуктов. Так каков продукт у нашего?

>> И да, он ускоряет реакцию, а не смещает равновесие.
> Именно.  Дело и есть в том, что нынешняя точка является далеко
> не равновесной.

Причём даже 1% катализатора не сильно процесс и ускоряет. Может ,катализатор неэффективный?

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

Для возможности достаточно OS, а не UW.

>> А логике и интерфейсу достаточно пользовательских прав.
>> А в никсах да, права передаются всей программе.
> Чего?!

sudo asmarctcl даёт права рута всей smartctl, а не только тому участку, что действительно нуждается в таких правах.

>> Ведь у вас скрипт под рутом запускается, так?
> Да -- потому что я доверяю задействованным компонентам по опыту.  И
> если потребуется, вполне в состоянии переделать на вариант с понижением [требуемого
> уровня] доверия.

А пользователю тоже доверять его скрипту? А также скрипту, передающемуся as is?

Да, а по опыту вы под рутом работаете? Или вы скриптам доверяете больше, чем себе?

> Спасибо, конечно, но я ведь про общий случай.

В вакууме?

> Хотя, точнее, про Debian'овский.

Ой, это опять лучше в debian-russian@.  Совершенно не удивлюсь, если тоже подбросят каких небольших тематических феймворков.

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

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

> И опять-таки, раз, по-вашему, пользовательский ввод - важная причина поломки скриптов,
> то ваши парсеры... дополните сами.

Разумеется.  Особенно ещё не написанные.

> Скажем, значение локалей.  Это если их обрабатывать надо, а не просто
> тупо в C делать.

Эээ... так и что?

$ LC_TIME=C date +%B          
August
$ LC_TIME=ru_RU.UTF-8 date +%B
Август
$ LC_TIME=ja_JP.utf8 date +%B
8月

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

> Со списком переменных окружения, которые могут делать и прикладные программы, ещё хуже.

Продолжаю не видеть (mis)use case.  Не из вредности -- видимо, спать уж пора...

>>> Этим правда пользуются миллионы? Всмысле, у данных программ - миллионы пользователей?
> Да, спросите. По поводу пользователей, а не админов.

Пользователи инитскрипта СУБД обычно всё-таки админы, смею заметить.

> Так мнения сошлись в том, в чём раньше расходились. Причём моё мнение
> осталось неизменным.

А что оно -- обязательно должно было измениться, что ли? :-)

>>> Катализатор ускоряет превращение одного вещества в другое, а не в себя.
>> Почитайте про автокаталитические реакции.
> В них катализатор - один из продуктов. Так каков продукт у нашего?

У альтов девиз -- free software for free people.

> Может, катализатор неэффективный?

Может, ингибитора куча навалена.  Считая и внутренний.

>>> Механизм тоже непонятен - как необходимость программирования на С может что-то
>>> увеличить - на ингибитор больше похоже.
>> Необходимость не может, а вот возможность -- вполне.
> Для возможности достаточно OS

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

> а не UW.

?

>>> А в никсах да, права передаются всей программе.
>> Чего?!
> sudo smartctl даёт права рута всей smartctl, а не только тому участку,
> что действительно нуждается в таких правах.

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

См., например, http://git.altlinux.org/people/mike/packages/?p=mtr.git;a=bl...

То есть предложенный тезис неверен.

>>> Ведь у вас скрипт под рутом запускается, так?
>> Да -- потому что я доверяю задействованным компонентам по опыту.
> А пользователю тоже доверять его скрипту? А также скрипту, передающемуся as is?

А это уж дело пользователя.

> Да, а по опыту вы под рутом работаете?

Когда требуются привилегии рута -- разумеется, под рутом.

> Или вы скриптам доверяете больше, чем себе?

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

>> Спасибо, конечно, но я ведь про общий случай.
> В вакууме?

Недистрибутивоспецифичные.

>[оверквотинг удален]
> $ LC_TIME=C date +%B
> August
> $ LC_TIME=ru_RU.UTF-8 date +%B
> Август
> $ LC_TIME=ja_JP.utf8 date +%B
> 8月
> Разумеется, парсить какой-то произвольный вывод (особенно если он именно локализован,
> а не просто переведён, и в случаях RTL включительно) -- гораздо
> больше мороки.  Но что-то сходу таких надобностей опять же не
> припомню, хотя и не исключаю.

Надобность в том, что это учитывать надо. В смысле, знать. И да, раньше кодировок несколько было у локалей.

>> Со списком переменных окружения, которые могут делать и прикладные программы, ещё хуже.
> Продолжаю не видеть (mis)use case.  Не из вредности -- видимо, спать
> уж пора...

Ну, скажем, как, не читая документации, узнать о moz_disable_pango ?

>>>> Этим правда пользуются миллионы? Всмысле, у данных программ - миллионы пользователей?
>> Да, спросите. По поводу пользователей, а не админов.
> Пользователи инитскрипта СУБД обычно всё-таки админы, смею заметить.

Я в курсе. Поэтому и интересуют пользователи. Вы же про редкие жалобы пользователей писали в 164? А админы, как и прогеры, прогибаются под реальность, да и сами способны скрипты доделать.

>> Так мнения сошлись в том, в чём раньше расходились. Причём моё мнение
>> осталось неизменным.
> А что оно -- обязательно должно было измениться, что ли? :-)

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

>>>> Катализатор ускоряет превращение одного вещества в другое, а не в себя.
>>> Почитайте про автокаталитические реакции.
>> В них катализатор - один из продуктов. Так каков продукт у нашего?
> У альтов девиз -- free software for free people.

У мелкософта - создай будущее.

И всё-таки, какой продукт и кто его получение должен катализировать? Поконкретнее, пожалуйста.

>> Может, катализатор неэффективный?
> Может, ингибитора куча навалена.  Считая и внутренний.

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

>>>> Механизм тоже непонятен - как необходимость программирования на С может что-то
>>>> увеличить - на ингибитор больше похоже.
>>> Необходимость не может, а вот возможность -- вполне.
>> Для возможности достаточно OS
> Строго говоря, нет: исходники могут давать без права для чего-либо их применять.

И, тем не менее, плюшки при программировании это какие-то даёт.

>> а не UW.
> ?

unix-way. В смысле, программить и под винду можно. Что, показывает опыт, происходит более эффективно и без os.

>>>> А в никсах да, права передаются всей программе.
>>> Чего?!
>> sudo smartctl даёт права рута всей smartctl, а не только тому участку,
>> что действительно нуждается в таких правах.
> Если разница заслуживает внимания, такие программы дерибанятся на работающие с повышенными
> и пониженными (возможно, ещё и в чруте) части.  

Я думаю, вы слишком оптимистичны.  В Unix многое чего заслуживает внимание. Но делается при этом много меньше.

> То есть предложенный тезис неверен.
>>>> Ведь у вас скрипт под рутом запускается, так?
>>> Да -- потому что я доверяю задействованным компонентам по опыту.
>> А пользователю тоже доверять его скрипту? А также скрипту, передающемуся as is?
> А это уж дело пользователя.

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

>> Да, а по опыту вы под рутом работаете?
> Когда требуются привилегии рута -- разумеется, под рутом.

То есть, проведя аналогию, ваш скрипт целиком рута требует?

>> Или вы скриптам доверяете больше, чем себе?
> Написанным собственноручно в здравом уме скриптам можно доверять и больше, чем уставшему
> себе.  

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

>>> Спасибо, конечно, но я ведь про общий случай.
>> В вакууме?
> Недистрибутивоспецифичные.

Сходу затруднюсь подсказать.  libshell не является дистрибутивоспецифичным в том плане, что это весьма мобильный код на POSIX shell; просто в альте он уже упакован и активно используется.

> Надобность в том, что это учитывать надо. В смысле, знать.

Разумеется.  Без знаний делать вообще сложно.

> И да, раньше кодировок несколько было у локалей.

Да их и сейчас бывает несколько -- вон рядом две терминалки висят в разных ru_RU.*...

> Ну, скажем, как, не читая документации, узнать о moz_disable_pango ?

Например, грепом; это даже не шутка.

> Я в курсе. Поэтому и интересуют пользователи. Вы же про редкие жалобы
> пользователей писали в 164? А админы, как и прогеры, прогибаются под
> реальность, да и сами способны скрипты доделать.

Тем не менее пожаловаться/прислать патч обычно сподвигаются чаще, чем поблагодарить за то, что всё и так работает. :-)

> И всё-таки, какой продукт и кто его получение должен катализировать?
> Поконкретнее, пожалуйста.

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

Многолетние наблюдения за пользователями Linux и Windows показывают, что шансов отупеть до состояния "оно там чё-то сделало и вот" на линуксе гораздо меньше даже у тех пользователей, которые не склонны лезть под капот чуть что.

> Тогда возникает вопрос - кто же этот яд?

Ложь и есть этот яд.

> В смысле, программить и под винду можно. Что, показывает опыт,
> происходит более эффективно и без os.

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

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

См. тж. http://www.opennet.me/openforum/vsluhforumID3/60559.html#54

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

Думаю, более чем реалистичен, а ссылочек вроде предложенной ещё несколько десятков накидать могу,

> В Unix многое чего заслуживает внимание. Но делается при этом много меньше.

Да, конечно.  Тем не менее честно тягаться с достигнутыми результатами пока никому особо не удавалось -- ни более технологичному VMS, ни сдавшейся MacOS, ни выкидывающим дикие фортели Windows.

> А как пользователь может делать вывод, особенно если он неопытен

Разве что спросив совета или пораскинув мозгами.

> а скрипт написан с нуля, что увеличивает вероятность ошибок?

Это с чего бы?  Скрипт переписан из ставшей слишком длинной строчки в history, которая была более чем отлажена практическим применением.

>>> Да, а по опыту вы под рутом работаете?
>> Когда требуются привилегии рута -- разумеется, под рутом.
> То есть, проведя аналогию, ваш скрипт целиком рута требует?

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

> Про уставшего речи не было.

К этому тоже можно вернуться годиков через десять.

> А "здравый ум" - это, я так понимаю, режим безошибочного написания скриптов.

Скорее возможность выделить достаточно непрерывного внимания при написании и отладке плюс просто нормальное физическое состоянние.

>>>> Спасибо, конечно, но я ведь про общий случай.
>>> В вакууме?
>> Недистрибутивоспецифичные.
> Сходу затруднюсь подсказать.  libshell не является дистрибутивоспецифичным в том плане,
> что это весьма мобильный код на POSIX shell; просто в альте
> он уже упакован и активно используется.

В Debian активно используется perl. В Мандриве, кстати, на нём был написан drakconf. suse тоже не на шелле написан. Альтератор на схеме. Вполне возможно, надобность в шелле исчезла. А в альте он зачем-то нужен.

>> Надобность в том, что это учитывать надо. В смысле, знать.
> Разумеется.  Без знаний делать вообще сложно.

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

>> И да, раньше кодировок несколько было у локалей.
> Да их и сейчас бывает несколько -- вон рядом две терминалки висят
> в разных ru_RU.*...
>> Ну, скажем, как, не читая документации, узнать о moz_disable_pango ?
> Например, грепом; это даже не шутка.

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

>> Я в курсе. Поэтому и интересуют пользователи. Вы же про редкие жалобы
>> пользователей писали в 164? А админы, как и прогеры, прогибаются под
>> реальность, да и сами способны скрипты доделать.
> Тем не менее пожаловаться/прислать патч обычно сподвигаются чаще, чем поблагодарить за
> то, что всё и так работает. :-)

Вы уверены, что они будут слать патч к скрипту на шелле в несколько деляток строк?

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

Думающий человек - непременно знаток IT, если ими приходится пользоваться?

> Многолетние наблюдения за пользователями Linux и Windows показывают, что шансов отупеть
> до состояния "оно там чё-то сделало и вот" на линуксе гораздо
> меньше даже у тех пользователей, которые не склонны лезть под капот
> чуть что.

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

Ну и да, скопление пользователей в мире GNOME/KDE тоже намекает.

>> Тогда возникает вопрос - кто же этот яд?
> Ложь и есть этот яд.

А подробнее?

>> В смысле, программить и под винду можно. Что, показывает опыт,
>> происходит более эффективно и без os.
> Опыт опыту рознь, особенно если помимо написания учесть ещё отладку, доработку и
> затем неизбежное для сложных систем диагностирование на месте применения.

Опять-таки, опыт KDE/GNOME кое-что показывает...

> Впрочем, давайте к вопросу полезности исходников вне зависимости от платформы вернёмся
> годиков через десять, если будем живы и угораздит вспомнить.
> См. тж. http://www.opennet.me/openforum/vsluhforumID3/60559.html#54
>>> Если разница заслуживает внимания, такие программы дерибанятся на работающие
>>> с повышенными и пониженными (возможно, ещё и в чруте) части.
>> Я думаю, вы слишком оптимистичны.
> Думаю, более чем реалистичен, а ссылочек вроде предложенной ещё несколько десятков накидать
> могу,

Лучше ссылочек опрос людей помог бы.

>> В Unix многое чего заслуживает внимание. Но делается при этом много меньше.
> Да, конечно.  Тем не менее честно тягаться с достигнутыми результатами пока
> никому особо не удавалось -- ни более технологичному VMS, ни сдавшейся
> MacOS, ни выкидывающим дикие фортели Windows.

Ну если 98 % - это "никому не удавалось тягаться"...

>> А как пользователь может делать вывод, особенно если он неопытен
> Разве что спросив совета или пораскинув мозгами.

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

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

Сами же писали - обработка неожиданного ввода. Который даже тестами целиком не отлаживается. Которые ещё и уметь писать надо. А до этого про эту методику знать.

>>>> Да, а по опыту вы под рутом работаете?
>>> Когда требуются привилегии рута -- разумеется, под рутом.
>> То есть, проведя аналогию, ваш скрипт целиком рута требует?
> То есть он буквально от рута целиком мной и запускается.

Запускается целиком, но действительно требует рута очень небольшая его часть.

>> Про уставшего речи не было.
> К этому тоже можно вернуться годиков через десять.
>> А "здравый ум" - это, я так понимаю, режим безошибочного написания скриптов.
> Скорее возможность выделить достаточно непрерывного внимания при написании и отладке плюс
> просто нормальное физическое состоянние.

Ну если внимание заменяет знание и опыт...

> В Debian активно используется perl. В Мандриве, кстати, на нём был написан
> drakconf. suse тоже не на шелле написан.

IIRC тоже в заметной части на перле, хотя что-то смутно припоминается питоновое в последнее время.

> Альтератор на схеме.

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

Кстати, на удивление неплохой получилась работа с достаточно сложными структурами данных -- заполнить весьма разнообразную HTML-форму можно буквально несколькими экранами шеллового скрипта и половиной экрана схемы.  См., например,
http://git.altlinux.org/gears/a/alterator-control.git?p=alte...
http://git.altlinux.org/gears/a/alterator-control.git?p=alte...
http://git.altlinux.org/gears/a/alterator-control.git?p=alte...

> Вполне возможно, надобность в шелле исчезла.

Ну так отодвиньте /bin/sh и посмотрите, точно ли. :)

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

Ой да...

>>> Ну, скажем, как, не читая документации, узнать о moz_disable_pango ?
>> Например, грепом; это даже не шутка.
> Грепом, если я правильно понял ответ, можно найти переменную, имя которой известно.

Отнюдь, grep -ri "something relevant" помогает гораздо чаще, чем может показаться.  Хотя "дикий" поиск информации и впрямь сложно формализуем.

> Вы уверены, что они будут слать патч к скрипту на шелле в несколько деляток строк?

К extfs за несколько лет по строчке-другой несколько патчиков пришло.  Один или два были как раз про учёт немного изменившегося вывода isoinfo(1) и я был весьма недоволен его разработчиками, кстати о начале субтреда.

> Думающий человек - непременно знаток IT, если ими приходится пользоваться?

Разумеется, нет.  Но "винда что-то там сделала и..." как раз думающих заставляет задуматься.

> То есть, вместо автоматизированной системы получаем фактически систему с ручным
> управлением. За исключением ,конечно, дистрибутивоспецифичной автоматизации.

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

>>> Тогда возникает вопрос - кто же этот яд?
>> Ложь и есть этот яд.
> А подробнее?

Когда Microsoft рассказывает, что бесплатный линукс -- это несолидно/небезопасно/unamerican/whatever, получается ложь; но люди поспешные и неразборчивые могут и такое заглотить, особенно если под что-то более правдоподобное.  Такая ложь тоже отравляет людей, причём в этом случае главная беда -- не "препятствия линуксу", а сознательное решение солгать.

> Лучше ссылочек опрос людей помог бы.

Так не первый год общаюсь с Димой Левиным (ldv@) и Александром Песляком (solardiz), руками которых многие из патчей по тем ссылочкам и выполнены.

>>> В Unix многое чего заслуживает внимание. Но делается при этом много меньше.
>> Да, конечно.  Тем не менее честно тягаться с достигнутыми результатами пока
>> никому особо не удавалось -- ни более технологичному VMS, ни сдавшейся
>> MacOS, ни выкидывающим дикие фортели Windows.
> Ну если 98 % - это "никому не удавалось тягаться"...

В дополнение к выделению жирным могу предложить материалы http://ftp.linux.kiev.ua/pub/mirrors/iowaconsumercase.org/

>>> А как пользователь может делать вывод, особенно если он неопытен
>> Разве что спросив совета или пораскинув мозгами.
> Я всё-таки надеялся на ответ "обучение" с последующим вопросом " а у кого?"

Чуть сократил Вам путь. :)

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

OR != XOR :)  И да, такой бутстрап возможен на минимуме знаний и опыта.  Сам дёргал знакомого две недели телефоном (не было даже модема), а через месяца три уже ему что-то подсказал по администрированию.

> Сами же писали - обработка неожиданного ввода.

У скрипта, который ввод не принимает, угу. :]

> Запускается целиком, но действительно требует рута очень небольшая его часть.

Да.

> Ну если внимание заменяет знание и опыт...

Вы удивитесь, но нередко даже именно заменяет.  А вот знание и опыт без внимания бывают крайне чреваты.

> Вы будете сильно удивлены, но в паре с шеллом: хотя есть возможность
> писать и перловые, и схемные backend'ы, шелл ближе сисадмину -- а
> это тот, чьи знания как раз и стоит помогать формализовать в
> управлялке.

Основной язык, я так понимаю - схема.

> Кстати, на удивление неплохой получилась работа с достаточно сложными структурами данных
> -- заполнить весьма разнообразную HTML-форму можно буквально несколькими экранами шеллового
> скрипта и половиной экрана схемы.  См., например,
> http://git.altlinux.org/gears/a/alterator-control.git?p=alte...
> http://git.altlinux.org/gears/a/alterator-control.git?p=alte...
> http://git.altlinux.org/gears/a/alterator-control.git?p=alte...

Сгенерировать HTML-форму - не обработать. Про обработку ajax молчу.

Нет, я не спорю, что на bash кто-то пишет. Я видел большие приложения на bash. Вопрос в удобстве использования, простоте чтения и изменения. Профи и  на brainfuck напишет. Для пользователя инструмент критичен.

>> Вполне возможно, надобность в шелле исчезла.
> Ну так отодвиньте /bin/sh и посмотрите, точно ли. :)

Я bin/sh и не придвигал. Придвинул было tcl/tk, да модулей не оказалось.

>> Но знания добываться могут разными путями, которые по сложности разительно отличаются.
> Ой да...

Ага. Не зря есть учебные учреждения, например.

>>>> Ну, скажем, как, не читая документации, узнать о moz_disable_pango ?
>>> Например, грепом; это даже не шутка.
>> Грепом, если я правильно понял ответ, можно найти переменную, имя которой известно.
> Отнюдь, grep -ri "something relevant" помогает гораздо чаще, чем может показаться.  

something relevant, в данном случае, были тормоза мозиллы. Которые через google выводили на переменную. Так что покажите, что подставить в grep-то?

>> Вы уверены, что они будут слать патч к скрипту на шелле в несколько деляток строк?
> К extfs за несколько лет по строчке-другой несколько патчиков пришло.  Один
> или два были как раз про учёт немного изменившегося вывода isoinfo(1)
> и я был весьма недоволен его разработчиками, кстати о начале субтреда.

Скриптом, скорее всего, чаще пользовались. Это же не init-скрипт.

>> Думающий человек - непременно знаток IT, если ими приходится пользоваться?
> Разумеется, нет.  Но "винда что-то там сделала и..." как раз думающих
> заставляет задуматься.

А вы читали форумы ubuntu?

>> То есть, вместо автоматизированной системы получаем фактически систему с ручным
>> управлением. За исключением ,конечно, дистрибутивоспецифичной автоматизации.
> Смотря какой результат требуется от совокупности произведённых ручных и автоматизированных
> действий.  

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

>>>> Тогда возникает вопрос - кто же этот яд?
>>> Ложь и есть этот яд.
>> А подробнее?
> Когда Microsoft рассказывает, что бесплатный линукс -- это несолидно/небезопасно/unamerican/whatever,
> получается ложь; но люди поспешные и неразборчивые могут и такое заглотить,
> особенно если под что-то более правдоподобное.  Такая ложь тоже отравляет
> людей, причём в этом случае главная беда -- не "препятствия линуксу",
> а сознательное решение солгать.

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

>> Лучше ссылочек опрос людей помог бы.
> Так не первый год общаюсь с Димой Левиным (ldv@) и Александром Песляком
> (solardiz), руками которых многие из патчей по тем ссылочкам и выполнены.

Опрос пользователей на тему системы управления правами доступа.

>>>> В Unix многое чего заслуживает внимание. Но делается при этом много меньше.
>>> Да, конечно.  Тем не менее честно тягаться с достигнутыми результатами пока
>>> никому особо не удавалось -- ни более технологичному VMS, ни сдавшейся
>>> MacOS, ни выкидывающим дикие фортели Windows.
>> Ну если 98 % - это "никому не удавалось тягаться"...

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

> В дополнение к выделению жирным могу предложить материалы http://ftp.linux.kiev.ua/pub/mirrors/iowaconsumercase.org/
>>>> А как пользователь может делать вывод, особенно если он неопытен
>>> Разве что спросив совета или пораскинув мозгами.
>> Я всё-таки надеялся на ответ "обучение" с последующим вопросом " а у кого?"
> Чуть сократил Вам путь. :)

Жалко, что сократили другой путь.

>> но раз конкретные ответы на конкретные вопросы важнее фундаментального знания,
>> а раскидывание мозгами возможно без знаний и опыта...
> OR != XOR :)  И да, такой бутстрап возможен на минимуме
> знаний и опыта.  

Возможен, может быть. Но не типичен.

>> Сами же писали - обработка неожиданного ввода.
> У скрипта, который ввод не принимает, угу. :]

А! Скрипт ввод не принимает? Ну тогда другое дело.

>> Запускается целиком, но действительно требует рута очень небольшая его часть.
> Да.

Но, тем не менее, повышенные права передаются всему скрипту.

>> Ну если внимание заменяет знание и опыт...
> Вы удивитесь, но нередко даже именно заменяет.  А вот знание и
> опыт без внимания бывают крайне чреваты.

Опыт без внимания называется рефлекс. Когда делается что-то, но даже не осознаётся. Скажем, слепая печать.

А знание без внимания да, чреваты. Но всё-таки сильно лучше, чтобы они были.

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

> Основной язык, я так понимаю - схема.

Да.  Но шелл используется очень сильно и уместно.

> Сгенерировать HTML-форму - не обработать. Про обработку ajax молчу.

А это всё от и до -- сгенерировать, об'ajax'ить, обработать.

> something relevant, в данном случае, были тормоза мозиллы. Которые через google
> выводили на переменную. Так что покажите, что подставить в grep-то?

Значит, в данном случае грепать пришлось интернет -- а предложенный способ на универсальность и не претендовал.

> А вы читали форумы ubuntu?

Читал, отчасти потому к Шатлворту и предъявы такие.

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

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

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

Если бы это всё было определяющим, то сидели бы они и поныне на System 9 какой.  Возможно, даже на потомке тех m68k или ppc.  И ни разу не на хламе вроде win 3.x, win95, nt4 и их потомства.

>>> Лучше ссылочек опрос людей помог бы.
> Опрос пользователей на тему системы управления правами доступа.

Что-то я Вас не понимаю.

> Я думаю, выделить нужно "некоторыми достигнутыми результатами".

Что написал, то написал.

>>> Сами же писали - обработка неожиданного ввода.
>> У скрипта, который ввод не принимает, угу. :]
> А! Скрипт ввод не принимает? Ну тогда другое дело.

А разве по нему это не очевидно?

>>> Запускается целиком, но действительно требует рута очень небольшая его часть.
>> Да.
> Но, тем не менее, повышенные права передаются всему скрипту.

Да.  И в данном случае это несущественно.  Если хотите, то всё-таки почитайте его и прикиньте модель угроз.

> Но, в принципе, я понял вашу позицию - скрипты возможно писать без знаний.

Да, возможно.  Но лучше со знаниями.

> Нужно пользователям об этом сказать - вот удивятся. Только все претензии по потере
> информации к вам, ок?

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

>> Основной язык, я так понимаю - схема.
> Да.  Но шелл используется очень сильно и уместно.

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

>> Сгенерировать HTML-форму - не обработать. Про обработку ajax молчу.
> А это всё от и до -- сгенерировать, об'ajax'ить, обработать.
>> something relevant, в данном случае, были тормоза мозиллы. Которые через google
>> выводили на переменную. Так что покажите, что подставить в grep-то?
> Значит, в данном случае грепать пришлось интернет -- а предложенный способ на
> универсальность и не претендовал.

А вопрос весьма универсальный - обнаружить в системе "тёмные места".

>> А вы читали форумы ubuntu?
> Читал, отчасти потому к Шатлворту и предъявы такие.

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

К создателям suse и mandriva, кстати, предъяв нет?

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

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

>> Пользователям важна готовая к работе, искаробочная система и дружелюбное сообщество.
> Если бы это всё было определяющим, то сидели бы они и поныне
> на System 9 какой.  Возможно, даже на потомке тех m68k
> или ppc.  И ни разу не на хламе вроде win
> 3.x, win95, nt4 и их потомства.

Может и сидели, если бы в магазинах продавалось.

>>>> Лучше ссылочек опрос людей помог бы.
>> Опрос пользователей на тему системы управления правами доступа.
> Что-то я Вас не понимаю.

Спросить пользователей, как им нравится система разделения прав в существующей системе. Скажем, необходимость ставить пакеты из-под рута. Монтирование под рутом.  Или создание под рутом ( и только под ним) жёсткой ссылки на каталог.

>> Я думаю, выделить нужно "некоторыми достигнутыми результатами".
> Что написал, то написал.

Я тоже написал, что подумал.

>>>> Сами же писали - обработка неожиданного ввода.
>>> У скрипта, который ввод не принимает, угу. :]
>> А! Скрипт ввод не принимает? Ну тогда другое дело.
> А разве по нему это не очевидно?

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

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

Конкретно в нём - несущественно. Существенно, если таких скриптов много (а их будет много - автоматизировать есть чего), и где-то будет проявлена невнимательность. Или со временем среда изменится.

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

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

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

Не забывайте, кстати, что, помимо невнимательности, есть ещё и недопонимание.  Ограничения языкового представления информации, знаете ли.

> Схема, кстати, в других местах такой же антиквариат.

Согласен, уже 2.0 на дворе, но портироваться с 1.8 пока смысла не видно.

А если Вы о "современных" языках программирования -- могу предложить КМБ в виде http://www.altlinux.org/Scheme/Tutorial и книжку для IMHO любого уважающего себя разработчика http://ftp.linux.kiev.ua/pub/docs/developer/general/sicp-ru/ да подумать не спеша: а так ли много полезного изобрели после лиспа.

> А вопрос весьма универсальный - обнаружить в системе "тёмные места".

У меня есть ещё более универальные вопросы и на них ещё сложнее ответить.  Если требуется руководство к действию, ищем способ сузить область поиска ответа; если требуется покрасоваться -- можно задавать сколь угодно универсальные вопросы и ждать ответа.

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

Чуточку.

> К создателям suse и mandriva, кстати, предъяв нет?

К _создателям_ SuSE и Mandrake -- нет.  Нынешняя openSUSE вовсю играет в проприетаризацию того же OBS (что понятно, надо же им где-то деньги на разработку отбивать; хотя и здесь на обнинской конференции Стоволосов кой-чего уточнял).  А нынешняя Mandriva -- это даже не смех сквозь слёзы, а просто развод.

> По рецептам нужно разбираться и нужно скрипты писать.

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

> То есть тратить своё драгоценное время на то, что должно просто работать.

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

>>>>> Лучше ссылочек опрос людей помог бы.
>>> Опрос пользователей на тему системы управления правами доступа.
>> Что-то я Вас не понимаю.
> Спросить пользователей, как им нравится система разделения прав в существующей системе.

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

> Скажем, необходимость ставить пакеты из-под рута. Монтирование под рутом.

То есть про capabilities ничего не слышали.

> Или создание под рутом (и только под ним) жёсткой ссылки на каталог.

1) зачем?
2) и где такое делается?
3) знакомы ли Вы с использованием хардлинков на каталог в юниксовых ФС?

> Вообще-то это был сарказм. Ввод в скрипте запрятан в виде списка тех же дисков.

Это не ввод, а "прибито гвоздями".

> Изменилась конфигурация определённым образом - и скрипт может полететь.
> Или отобразить не всё.

Какой ужас, а запускает его полный кретин с амнезией, случайно получивший физический доступ к хосту, наверное.

>>> Но, тем не менее, повышенные права передаются всему скрипту.
>> Да.  И в данном случае это несущественно.
> Конкретно в нём - несущественно.

На чём предлагаю переливание из пустого в порожнее по *этому* поводу и закончить.

>> А хотите моей ответственности -- так она за сказанное мной без опосредования кем-либо.
> Без посредника. Вы же сами, как катализатор, собираетесь об этом говорить окружающим?

Я и говорю.

> Вы согласны отвечать за последствия в этом случае? И прямо об этом писать?

Я отвечаю за каждое сказанное или написанное мной слово.

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

Разумеется, наоборот.

> Не забывайте, кстати, что, помимо невнимательности, есть ещё и недопонимание.

Как тут забудешь, когда через абзац живо напоминаете...

>> Схема, кстати, в других местах такой же антиквариат.
> Согласен, уже 2.0 на дворе, но портироваться с 1.8 пока смысла не
> видно.
> А если Вы о "современных" языках программирования -- могу предложить КМБ в
> виде http://www.altlinux.org/Scheme/Tutorial и книжку для IMHO любого уважающего себя
> разработчика http://ftp.linux.kiev.ua/pub/docs/developer/general/sicp-ru/ да подумать
> не спеша: а так ли много полезного изобрели после лиспа.

Не знаю, что изобрели, однако учитываю тот факт, что на схеме и шелле написан генератор html и js, отображаемый в программе, написанной на C/C++.

>> А вопрос весьма универсальный - обнаружить в системе "тёмные места".
> У меня есть ещё более универальные вопросы и на них ещё сложнее
> ответить.  

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

>> Но есть вы понимаете, на каких системах сидит большинство пользователей, что они
>> из себя представляют и как решают проблемы, а также какую документацию
>> пишут, если проблему решат?
> Чуточку.
>> К создателям suse и mandriva, кстати, предъяв нет?
> К _создателям_ SuSE и Mandrake -- нет.  Нынешняя openSUSE вовсю играет
> в проприетаризацию того же OBS (что понятно, надо же им где-то
> деньги на разработку отбивать; хотя и здесь на обнинской конференции Стоволосов
> кой-чего уточнял).  А нынешняя Mandriva -- это даже не смех
> сквозь слёзы, а просто развод.

Тема была не про разводы и проприетаризацию, а про квалификацию привлекаемых пользователей.

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

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

>> То есть тратить своё драгоценное время на то, что должно просто работать.
> Так результат разный -- от разбирательства может получиться понимание, а от "просто
> работает" его не будет; написанный скрипт может быть реюзабелен, а вот
> предлагаемой кнопкой поделиться с соседом может быть и нелегально.  Лукавите,
> сдаётся мне.

Да, от разбирательства можно получить много чего. Если разбираться приходится при чтении хорошего учебника, например. А не при чтении "кулинарного" рецепта. А при чтении рецепта разбираться приходится не в том, как оно работает, а почему не работает, или работает, но не так.

Я так понимаю, у вас третий тезис созрел - качество документации не играет роли, главное, что исходники есть.

>>>>>> Лучше ссылочек опрос людей помог бы.
>>>> Опрос пользователей на тему системы управления правами доступа.
>>> Что-то я Вас не понимаю.
>> Спросить пользователей, как им нравится система разделения прав в существующей системе.
> Это как -- если припудрить, то должна нравиться больше?  *Эта* целевая
> аудитория голосует ногами и откликается патчами.

"Целевая аудитория" - не пользователи.

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

А должен? Мне вот только диск примонтировать руками. Ну, в смысле, сделать то, что винда автоматом делала.

>> Или создание под рутом (и только под ним) жёсткой ссылки на каталог.
> 1) зачем?

Затем же, зачем делают жёсткие ссылки на файлы.

> 2) и где такое делается?

А должны быть прецеденты и я непременно должен об этом знать?

> 3) знакомы ли Вы с использованием хардлинков на каталог в юниксовых ФС?

А я должен, используя команды ln, и даже прочитав ей man, это знать?

>> Вообще-то это был сарказм. Ввод в скрипте запрятан в виде списка тех же дисков.
> Это не ввод, а "прибито гвоздями".

Прибивают гвоздями в бинарных программах. А здесь можно и приходится редактировать.

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

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

>>>> Но, тем не менее, повышенные права передаются всему скрипту.
>>> Да.  И в данном случае это несущественно.
>> Конкретно в нём - несущественно.
> На чём предлагаю переливание из пустого в порожнее по *этому* поводу и
> закончить.

Ок, по конкретно вашему скрипту вопросов больше нет.

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

То есть, за последствия отвечаете? Готовы приписку делать в советах?

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

Я внимательно вас слушаю...

>> Не забывайте, кстати, что, помимо невнимательности, есть ещё и недопонимание.
> Как тут забудешь, когда через абзац живо напоминаете...

Даже не знаю, как это воспринимать - как порицание или как уведомление...

> [...] тот факт, что на схеме и шелле написан генератор html и js,
> отображаемый в программе, написанной на C/C++.

:)

Там не только генератор, повторюсь.  Обработчик тоже.

> Это да, такие вопросы бывают. Но важно знать, почему на них трудно ответить.

Это к философам или (лучше) здравому смыслу.

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

А вот микроволновку -- разве что не уничтожить. :)

> В отличии от команд под рутом.

Кнопочка в этом плане чем-то лучше будто.

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

То, что я сейчас не собираюсь -- не гарантирует того, что завтра не _понадобится_ разобраться и, возможно, починить.

Если бы пресловутый ксероксовский принтер в MIT просто работал... :) (http://www.roddis.org/docs/essay.html)

> Я так понимаю, у вас третий тезис созрел - качество документации не
> играет роли, главное, что исходники есть.

Судя по этой попытке передёрнуть, не поверите, но лучшая документация по функциональности кода -- именно код, по определению.  А вот по дизайну, архитектуре, направлению развития её как раз писать стоит: http://lwn.net/Articles/504814/

>>> Спросить пользователей, как им нравится система разделения прав
>>> в существующей системе.
>> *Эта* целевая аудитория голосует ногами и откликается патчами.
> "Целевая аудитория" - не пользователи.

Пусть даже так; специально для Вас переформулирую: те, кого предложили спросить -- голосуют ногами и откликаются патчами по данной специфической теме.

>>> Скажем, необходимость ставить пакеты из-под рута. Монтирование под рутом.
>> То есть про capabilities ничего не слышали.
> А должен? Мне вот только диск примонтировать руками.

Необходимости-то нет.

> Ну, в смысле, сделать то, что винда автоматом делала.

Если udisks не устраивают и хочется руками -- пожалуйста, вперёд.

>>> Или создание под рутом (и только под ним) жёсткой ссылки на каталог.
>> 1) зачем?
> Затем же, зачем делают жёсткие ссылки на файлы.

Пожалуйста, ознакомьтесь с предметной областью.

>> 2) и где такое делается?
> А должны быть прецеденты и я непременно должен об этом знать?

Да, раз полезли наводить тень на плетень.

>> 3) знакомы ли Вы с использованием хардлинков на каталог в юниксовых ФС?
> А я должен, используя команды ln, и даже прочитав ей man, это знать?

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

>> Я отвечаю за каждое сказанное или написанное мной слово.
> То есть, за последствия отвечаете?

За последствия отвечает делающий.

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

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

>> Это да, такие вопросы бывают. Но важно знать, почему на них трудно ответить.
> Это к философам или (лучше) здравому смыслу.

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

>>>> По рецептам нужно разбираться и нужно скрипты писать.
>>> Необязательно, можно просто "возьмите десять яиц" и дальше по тексту.
>> Десять яиц не способны уничтожить кухню, знаете ли.
> А вот микроволновку -- разве что не уничтожить. :)

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

>> В отличии от команд под рутом.
> Кнопочка в этом плане чем-то лучше будто.

Лучше. Идёт из коробки (скрипты искать надо), тестируется (иначе программой  пользоваться не будут), делает если не ожидаемые, то стандартные вещи. Скрипт же под рутом непредсказуем.

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

Угу, разобраться с одним скриптом. С двумя. Если система такова, что требует искать такие скрипты в режиме нон-стоп (требования пользователя, а не аскета), то разбирание быстро надоедает.

> Если бы пресловутый ксероксовский принтер в MIT просто работал... :) (http://www.roddis.org/docs/essay.html)

Если бы закрытое ПО того времени работало, то у свободного не было бы причины появляться. А сейчас оно не сильно спасает - разобраться в той куче кода невозможно физически.

>> Я так понимаю, у вас третий тезис созрел - качество документации не
>> играет роли, главное, что исходники есть.
> Судя по этой попытке передёрнуть, не поверите, но лучшая документация по функциональности
> кода -- именно код, по определению.  

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

>>>> Спросить пользователей, как им нравится система разделения прав
>>>> в существующей системе.
>>> *Эта* целевая аудитория голосует ногами и откликается патчами.
>> "Целевая аудитория" - не пользователи.
> Пусть даже так; специально для Вас переформулирую: те, кого предложили спросить --
> голосуют ногами и откликаются патчами по данной специфической теме.

Я так поимаю, те, кого предложили спросить, оказались способными , по неизвестной причине, писать патчи.

>>>> Скажем, необходимость ставить пакеты из-под рута. Монтирование под рутом.
>>> То есть про capabilities ничего не слышали.
>> А должен? Мне вот только диск примонтировать руками.
> Необходимости-то нет.

Есть. Ибо автомонтирование не всегда работает. Начиная от supermount, и заканчивая современным udev. А книжки пользователю указывают на mount.

>> Ну, в смысле, сделать то, что винда автоматом делала.
> Если udisks не устраивают и хочется руками -- пожалуйста, вперёд.
>>>> Или создание под рутом (и только под ним) жёсткой ссылки на каталог.
>>> 1) зачем?
>> Затем же, зачем делают жёсткие ссылки на файлы.
> Пожалуйста, ознакомьтесь с предметной областью.

Я надеюсь, под предметной областью понимается не традиции использования инструмента? Иначе вся гибкость теряется к чёртовой бабушке.

>>> 2) и где такое делается?
>> А должны быть прецеденты и я непременно должен об этом знать?
> Да, раз полезли наводить тень на плетень.
>>> 3) знакомы ли Вы с использованием хардлинков на каталог в юниксовых ФС?
>> А я должен, используя команды ln, и даже прочитав ей man, это знать?
> Да, должны, если задаётесь таким вопросом.  Это даже у Робачевского, кажется,
> описано.

Вы хоть понимаете, что мы говорим о политике использования, а не о причинах архитектурных изысканий?

>>> Я отвечаю за каждое сказанное или написанное мной слово.
>> То есть, за последствия отвечаете?
> За последствия отвечает делающий.

А ответ за слова - это что тогда?

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

Так обсуждение не с вопроса началось. А с того, попытки катализатора ускорить реакцию провалились, но причины этого не осознаются и не обсуждаются. А разговоры о том, что некие действия приведут к результату, не подтверждаются на практике. И да, планов - громадье. Но КПД близок к 0.

>> В отличии от команд под рутом.
>> Кнопочка в этом плане чем-то лучше будто.
> Лучше. Идёт из коробки (скрипты искать надо),

Ну покажите мне в какой угодно коробочке кнопку "сбэкапить мою почту, исключив спамбокс, и проиндексировать с задействованием морфологии русского".  Подсказка: это rsync или offlineimap плюс recollindex (или что ещё по вкусу).  Две строки -- не искать, а написать.

> тестируется (иначе программой  пользоваться не будут)

Самому не смешно?  Вспомните win95 и перечитайте данный жутко оптимистичный тезис.

> делает если не ожидаемые, то стандартные вещи.

Нафига мне стандартные вещи, если нужны ожидаемые _мной_, а не тем постановщиком сферической задачи?

> Скрипт же под рутом непредсказуем.

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

>> То, что я сейчас не собираюсь -- не гарантирует того, что завтра
>> не _понадобится_ разобраться и, возможно, починить.
> Угу, разобраться с одним скриптом. С двумя. Если система такова, что требует
> искать такие скрипты в режиме нон-стоп (требования пользователя, а не аскета),
> то разбирание быстро надоедает.

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

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

Так оно работало.  Просто поймите наконец -- не получается предусмотреть всё заранее.  Равно как и не получается любой софт развивать именно как открытый проект.  Только балансы у этих неполучалок разные...

> А сейчас оно не сильно спасает - разобраться в той куче кода невозможно физически.

Вот этому и помогают ясные интерфейсы и "набор острых инструментов".

> Не совсем. Ещё нужны комментарии к коду, хорошие комментарии

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

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

Да, TopSpeed'овский был хорош.

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

Скажем, сейчас picolisp довольно интересен в этом плане, хотя для желающих подобного уже очень давно доступен как минимум emacs.

> Я так поимаю, те, кого предложили спросить, оказались способными ,
> по неизвестной причине, писать патчи.

По наблюдениям.

>>>>> Скажем, необходимость ставить пакеты из-под рута. Монтирование под рутом.
>>>> То есть про capabilities ничего не слышали.
>>> А должен? Мне вот только диск примонтировать руками.
>> Необходимости-то нет.
> Есть. Ибо автомонтирование не всегда работает.

Вешайте баги, шлите патчи.

> Начиная от supermount

Вы-то им пользовались? :) (я -- да)

> и заканчивая современным udev.

Он вообще (то есть даже близко) не занимается монтированием, что характерно.

> А книжки пользователю указывают на mount.

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

>>> Затем же, зачем делают жёсткие ссылки на файлы.
>> Пожалуйста, ознакомьтесь с предметной областью.
> Я надеюсь, под предметной областью понимается не традиции использования инструмента?

Нет, юниксовые файловые системы и семантика их объектов.

> Иначе вся гибкость теряется к чёртовой бабушке.

Прошу обрисовать use case.

> Вы хоть понимаете, что мы говорим о политике использования,
> а не о причинах архитектурных изысканий?

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

>> За последствия отвечает делающий.
> А ответ за слова - это что тогда?

Это ответственность за их верность.  Она не может сама по себе гарантировать верность понимания и тем более верность выполнения.

> Так обсуждение не с вопроса началось. А с того, попытки катализатора ускорить
> реакцию провалились

Вообще-то бурно пошла другая реакция, но положим.

> но причины этого не осознаются и не обсуждаются.

Точно?

> А разговоры о том, что некие действия приведут к результату, не подтверждаются
> на практике. И да, планов - громадье. Но КПД близок к 0.

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

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

PS: поправил очепятку.

>>> В отличии от команд под рутом.
>>> Кнопочка в этом плане чем-то лучше будто.
>> Лучше. Идёт из коробки (скрипты искать надо),
> Ну покажите мне в какой угодно коробочке кнопку "сбэкапить мою почту, исключив
> спамбокс, и проиндексировать с задействованием морфологии русского".  Подсказка: это rsync
> или offlineimap плюс recollindex (или что ещё по вкусу).  Две
> строки -- не искать, а написать.

Ваша задача несколько нетипична, но, как всегда проста. Задача чуть более сложная - бекап пользовательских данных. Как пользователь, я не знаю, какие данные - пользовательские, а какие - нет. Скажем, в /var могут быть как полезные данные, типа списка состояния установленных пакетов, так и всякие кеши. Ну и, разумеется, сбекапить хомяк. Учитывая те же самые проблемы (разные типы файлов в каталогах настройки) + файлы настройки в самом /home/user, + учесть тот факт, что со временем каталоги с настройками будут мигрировать в ~/.config, + не бекапить/восстанавливать каталоги, которые созданы программами, которые удалены + учитывать появление новых программ + возможность не бекапить те данные, которые не изменены пользователем. Это пока то, что пришло в голову.

То есть, по сути, нужна база данных^Wзнаний по тому, какие данные где содержатся, и возможность выбора тех типов данных, которые нужно сбекапить.

Осилите написание подобного скрипта за приемлемое время?

>> тестируется (иначе программой  пользоваться не будут)
> Самому не смешно?  Вспомните win95 и перечитайте данный жутко оптимистичный тезис.

Помню. Глючная. Менее глючная, чем 3.x. Мало ест ресурсов - запускается и работает на 80386 & 4 Мб.(для консоли в linux уже маловато) Почти беспроблемно работать вполне можно, если постоянно не устанавливать/удалять программы. Ну и по идее, бекап спасает. Всё (хотя, могу что-то забыть), с чем пришлось иметь дело, работало из коробки. Кнопочки без исходников вполне работали. Единственная проблема - загаживание реестра - решалась неизменностью среды. Охренительное количество ПО, которое работает и дело делает. Для пользователя, во всяком случае. Лёгкий офис, который, тем не менее, висивиг.

В общем, единственная система, позволяющая сегодня хоть как-то работать на слабом ПК и что-то полезное делать. Если бы её доработали - цены бы не было.

>> делает если не ожидаемые, то стандартные вещи.
> Нафига мне стандартные вещи, если нужны ожидаемые _мной_, а не тем постановщиком
> сферической задачи?
>> Скрипт же под рутом непредсказуем.
> Это кнопочка без исходников непредсказуема, а вот как раз поведение скрипта предсказать
> по результатам осмотра и при необходимости протестировать -- обычно возможно.

Вы не забывайте - пользователь не прочёл все маны по командам. Для тех, кто прочёл (то есть не пользователей), поведение предсказуемо, да.

>>> То, что я сейчас не собираюсь -- не гарантирует того, что завтра
>>> не _понадобится_ разобраться и, возможно, починить.
>> Угу, разобраться с одним скриптом. С двумя. Если система такова, что требует
>> искать такие скрипты в режиме нон-стоп (требования пользователя, а не аскета),
>> то разбирание быстро надоедает.
> Вы знаете, с 1998 как-то не надоело.  

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

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

Не работало, как ему хотелось. +он был программистом + программы были маленькие в те времена. Пользователи - не программисты, драйверов, в конце-концов, и такие объёмы кода, которые есть сейчас, необозримы. Так что свободное ПО без нормальной архитектуры системы (или простых для пользователей инструментов разработки) проигрывает, если не проиграло.

>> А сейчас оно не сильно спасает - разобраться в той куче кода невозможно физически.
> Вот этому и помогают ясные интерфейсы и "набор острых инструментов".

Ясные интерфейсы, как у smartctl, и острые инструменты типа регекспов, лексеров для регулярных грамматик, с помощью которых разбирают естественный язык, который от регулярности слишком далёк?

Ясные интерфейсы - это, скажем, протокол http. Протокол, идею которого не понимают разработчики современных утилит. И да, документация на эти интерфейсы рулит. Ну чтобы либо была БНФ грамматики, либо её легко построить можно было, дабы воспользоваться генератором парсеров и не сношать себе мозг регекспами.

>> Не совсем. Ещё нужны комментарии к коду, хорошие комментарии
> Я в курсе, потому ссылку с уточнением места и предложил.
>> и отладчик с претензией на простоту использования,
>> дабы код изучался в процессе работы.
> Да, TopSpeed'овский был хорош.
>> Ну и от некоторых других вещей зависит. Скажем,  у смолтока была какая-то
>> среда, объединявшая написание, отладку и использование.
> Скажем, сейчас picolisp довольно интересен в этом плане, хотя для желающих подобного
> уже очень давно доступен как минимум emacs.

Крутые ответы. Guile+bash, отладчик не под linux, picolisp и emacs на elisp. Разработчики оценят. Пользователи тоже.

>> Я так поимаю, те, кого предложили спросить, оказались способными ,
>> по неизвестной причине, писать патчи.
> По наблюдениям.

В результате наблюдений. А причина неизвестна.

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

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

>> Начиная от supermount
> Вы-то им пользовались? :) (я -- да)

Да, в mandrake 9.2. глючил, но уже не помню где.

>> и заканчивая современным udev.
> Он вообще (то есть даже близко) не занимается монтированием, что характерно.

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

>> А книжки пользователю указывают на mount.
> Книжки читает скорее будущий админ,

Я запомню эту фразу - тезис номер четыре. man'ы, как справочники по командам, а не фундаментальная документация, надеюсь, тоже не входят в читальный набор пользователя?

>>>> Затем же, зачем делают жёсткие ссылки на файлы.
>>> Пожалуйста, ознакомьтесь с предметной областью.
>> Я надеюсь, под предметной областью понимается не традиции использования инструмента?
> Нет, юниксовые файловые системы и семантика их объектов.

Семантика объектов - это даже не знаю где найти.

>> Иначе вся гибкость теряется к чёртовой бабушке.
> Прошу обрисовать use case.

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

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

Вы не знаете, что такое политика использования?

>>> За последствия отвечает делающий.
>> А ответ за слова - это что тогда?
> Это ответственность за их верность.  Она не может сама по себе
> гарантировать верность понимания и тем более верность выполнения.

Слова были такие - внимательность важнее знаний. Пользователь внимательно пишет скрипт при отсутствии знаний и теряет данные. Отвечаете за потерю?

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

Ещё лучше - катализатор ускорил совсем другую реакцию! Тем более, его эффективность под вопросом. А также компетентность тех, кто этот катализатор положил.

>> но причины этого не осознаются и не обсуждаются.
> Точно?

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

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

Прогресс - освоение синаптика в теме про редактирование пользователем программ на bash и C. Далеко пойдёт парень - освоит все настройки KDE.

> запускается и работает на 80386 & 4 Мб

врать нехорошо. пытается запуститься — да. вечно хрустит свопом — да. работает? ну, если вечный своп и минутное (а то и больше) время реакции на действия считать работой…

> Ваша задача несколько нетипична, но, как всегда проста.

Желаю и Вам обзавестись умением простое делать просто, а к сложному применять декомпозицию.

> Задача чуть более сложная - бекап пользовательских данных. Как пользователь, я не знаю,
> какие данные - пользовательские, а какие - нет.

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

> Скажем, в /var могут быть как полезные данные, типа списка состояния установленных
> пакетов, так и всякие кеши.

Что характерное, первое ожидается в /var/lib, второе -- в /var/cache.

> Ну и, разумеется, сбекапить хомяк.

Просто полностью, т.к. решать за пользователя (разве что за себя) нельзя.

> То есть, по сути, нужна база данных^Wзнаний по тому, какие данные где
> содержатся, и возможность выбора тех типов данных, которые нужно сбекапить.
> Осилите написание подобного скрипта за приемлемое время?

Если мне понадобится -- да, конечно.  Вам -- могу выставить предложение в ответ на ТЗ.

Собственно, я-то уже сконфигурировал себе bacula с учётом того, что и как надо бэкапить (и что _не_ надо).  Поэтому автоматизировать может быть смысл включаемые списки exclude'ов.

>> Самому не смешно?  Вспомните win95 и перечитайте данный жутко оптимистичный тезис.
> Помню. Глючная. Менее глючная, чем 3.x.

Более.

> Мало ест ресурсов - запускается и работает на 80386 & 4 Мб.

Вот только не надо рассказывать это видевшему на 80486DX/8M.  На 386SX/4M и 3.11 не слишком весело, но хоть как-то шевелилась.

> Лёгкий офис, который, тем не менее, висивиг.

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

> Так что свободное ПО [...] проигрывает, если не проиграло.

Ну Вы ещё тут попрыгайте с воплями "девелоперс-девелоперс" для полноты картины, ага.

> Ясные интерфейсы - это, скажем, протокол http.

Это который stateless?  Батенька, Вы вообще хоть с ним работали-то?..

> В смысле, пользователи должны патчи слать? Для багов нужно [...]

Ну я же шлю.  И мне шлют.

>>> и заканчивая современным udev.
>> Он вообще (то есть даже близко) не занимается монтированием, что характерно.
> Доброе утро. Он по событиям команды вызывает, в т. ч. и монтирование.

Доброе.  Предъявите rules из какого-либо проекта, который занимается именно монтированием -- может, и существует, но не встречал; при этом предлагаю поразмыслить над тем, что монтированием и в таком случае будет заниматься скрипт/команда, а вовсе не udev.

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

guru, n:
        A computer owner who can read the manual.

>> Нет, юниксовые файловые системы и семантика их объектов.
> Семантика объектов - это даже не знаю где найти.

Ну гляньте хоть обсуждения:
http://lwn.net/Articles/100617/
http://lwn.net/Articles/249823/
http://lwn.net/Articles/352115/

>>> Иначе вся гибкость теряется к чёртовой бабушке.
>> Прошу обрисовать use case.
> Равнозначность ссылок, в том числе при удалении.

Объекты разные -- один "конечен" в терминах ФС, другой является контейнером для таких или себе подобных.  Именно последнее (каталог как контейнер для каталогов) в *nix и обуславливает отличие применения жёстких ссылок для файлов и каталогов.

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

А что мешает собственно удалить?

> В случае мягких ссылок нужно костыли городить.

По зачистке висяков?

> Вы не знаете, что такое политика использования?

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

> Слова были такие - внимательность важнее знаний. Пользователь внимательно пишет
> скрипт при отсутствии знаний и теряет данные. Отвечаете за потерю?

Пользователь отвечает за запуск им скрипта.  Я отвечаю за свои слова.

А Вы балаболите.

> На винде есть работающие программы для тривиальных случаев

…и большая задница для чуть менее тривиальных.

>> На винде есть работающие программы для тривиальных случаев
> …и большая задница для чуть менее тривиальных.

Скриптовые ЯП для винды тоже есть, ага.

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

И как с деплойментом пресловутых модулей? ;-) // плавали, знаем

>>>> На винде есть работающие программы для тривиальных случаев
>>> …и большая задница для чуть менее тривиальных.
>> Скриптовые ЯП для винды тоже есть, ага.
> И как с деплойментом пресловутых модулей? ;-) // плавали, знаем

Какие модули в VBA?

>>> Скриптовые ЯП для винды тоже есть, ага.
>> И как с деплойментом пресловутых модулей? ;-) // плавали, знаем
> Какие модули в VBA?

А-аа, я-то думал, Вы хотя бы про Perl или Tcl.

Какой "язык", такие и модули.

>>>> Скриптовые ЯП для винды тоже есть, ага.
>>> И как с деплойментом пресловутых модулей? ;-) // плавали, знаем
>> Какие модули в VBA?
> А-аа, я-то думал, Вы хотя бы про Perl или Tcl.

У тикля с "модулями" вообще плохо. А Перл для Unix изначально писался, как замену зоопарку программ-регекспов.

> Какой "язык", такие и модули.

Хотя бы такой язык. В GUI у Unix ничего подобного нет.

Его наличие, его версия... ЧТО ПИТОН?

А чем тебе мешает Python?

unity хороший, на второй гном с него мну не тянет например ни капли.

по теме, хорошо, еще бы скайп на gtk переписали и совсем хорошо или gtk ашную альтернативу с такой же популярностью сделали google например и супер

Кто в курсе - на кой им там OpenGL вообще? Только для эффектов с анимашками или хоть как-то полезно приспособили?

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

Kwin, например, и без opengl может работать, причём, используя 2d аппаратное ускорение, и некоторые простые эффекты (типа полупрозрачности и тому подобного).

Да правильно все сделали. Стартанули по быстрому отладили оптимизировали и выбрали лучшее.
Одна кодовая база всегда лучше. OpenGL 2.0 - это минимальный, который требуется поддерживают карты 10 летней давности.
Кто бы что не говорил самая быстрая оболочка под линукс была KDE 3.5.
Пора уже приводить в порядок 3D в линуксе!

> Пора уже приводить в порядок 3D в линуксе!

у меня с «3д в линуксе» всё ок. может, это не в консерватории проблемы, а ты играть не умеешь?

OpenGL 2.0 существует всего 10 лет, как десятилетние видяхи могут его поддерживать?

> Кто бы что не говорил самая быстрая оболочка под линукс была KDE
> 3.5.

Некислое замечание. Вообще-то, если вы бы хоть чутка посмотрели вокруг, вы увидели бы огромное количество быстрых оболочек, по сравнению с которыми KDE даже версий 1.х - тормоз. Не говоря уж о KDE3.

Эмм... Ок, человеческих оболочек :) В смысле, не для красноглазых.

В то время как GNOME shell в Fedora прекрасно работает даже на очень старых видяхах.

> В то время как GNOME shell в Fedora прекрасно работает даже на очень старых видяхах.

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

> В то время как GNOME shell в Fedora прекрасно работает даже на
> очень старых видяхах.

нет. у меня на nvidia 550ti c последними закрытыми дровами работает как-то криво.
Даёшь Gnome3 без анимации!

Шикарно.
Вот и выбирай, будучи владельцем ноутбука с гибридной видеокартой - либо тратишь больше заряда батареи, задействуя дискретную видеокарту, либо тратишь больше заряда батареи, пока процессор программно обеспечивает opengl.
Они вообще там мозгами думают? Ну на кой сдались обязательные 3D-эффекты в DE?

Тестил на своём Атоме 2д и 3д Юниты, время работы и скорость одинаковые.

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

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

А зачем задействовать дискретную видеокарту?

а не приходила в голову мысль о том, что покупка ноутбука с "гибридной видеокартой" была не лучшей идеей?

Использую KDE, ноутбук с nvidia optimus, идея гибридной видеокарты работает как надо ( экономия энергии когда дискретная видеокарта не нужна).
Меня огорчает, что KDE это теперь единственное DE из нормальных DE для ноутбука, которое может полноценно работать без 3D.

> Использую KDE, ноутбук с nvidia optimus, идея гибридной видеокарты работает как надо
> ( экономия энергии когда дискретная видеокарта не нужна).
> Меня огорчает, что KDE это теперь единственное DE из нормальных DE для
> ноутбука, которое может полноценно работать без 3D.

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

http://www.ixbt.com/portopc/optimus-2.shtml

Так бы и поверил, если бы сам лично не пользовался nvidia optimus

> Так бы и поверил, если бы сам лично не пользовался nvidia optimus

а тут не надо верить, выбраны совершенно одинаковые ноутбуки, с оптимусом и без.
а вам есть на чем вообще проверять-то? или вы на одном ноутбуке собираетесь сравнивать с... тем же ноутбуком? молодцы!

Интересно, мне одному кажется, что совмещать панель и оконный менеджер не оень хорошая идея? Если юнити падает, то ты остаешься только с обоями на рабочем столе..

А может лучше им сделать, чтобы оно не падало? Но пока (который год) космонавт не осиливает? ;)

У меня с самого выхода стоит и ни разу еще не упало, может у меня руки кривые?

> Оболочка Unity 2D исключена из состава Ubuntu 12.10

Суета это всё! (поглаживая лысенький животик Openbox"а)

Воистину! (выглядывая из ion3)

Подтверждаю. *выглядывая из KDE 4.9 без композитного глюкалова

На Awesome хорошая погода, на Unity 3D опять идут дожди...

> На Awesome хорошая погода, на Unity 3D опять идут дожди...

WindowMaker занимается любимым делом и не мешается под ногами. :)

>> На Awesome хорошая погода, на Unity 3D опять идут дожди...
> WindowMaker занимается любимым делом и не мешается под ногами. :)

Пользователи wmii смотрят на unity 3d с недоумением.

Keep talking, bitches, сказал twm)

> Keep talking, bitches, сказал twm)

Real men don't bitch around WMs.

> Real men don't bitch around WMs.

Настоящие гуру выставляют состояния шины тумблерами в пошаговом режиме. И потому плевать хотели на WMs.

>> На Awesome хорошая погода, на Unity 3D опять идут дожди...
> WindowMaker занимается любимым делом и не мешается под ногами. :)

WindowMaker наше все

Вот тебе транскрипция, сидалище.
/ʊˈbʊntuː/

> Подтверждаю. *выглядывая из KDE 4.9 без композитного глюкалова

О! Спасибо за напоминание, у меня до сих пор KDE 4.8, надо бы обновиться, а то всё некогда...

Жму вашу руку из wmii )

> Суета это всё! (поглаживая лысенький животик Openbox"а)

Скорее, лёгкое беспокойство. Суета начинается с вещей аля Firefox.

>> Оболочка Unity 2D исключена из состава Ubuntu 12.10
> Суета это всё! (поглаживая лысенький животик Openbox"а)

MATE удобнее

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

12.04 уже стабилен можно на него переползать, проброс иксов есть ?
как бем проброса иксов ? vnc ?

> 12.04 уже стабилен?

Нет.

> можно на него переползать

Можно, если время гробить не на что.

>проброс иксов есть

Это как закажите. Со стразами али без...

>> 12.04 уже стабилен?
> Нет.

Вранье. Активность в репах более-менее устаканилась, etc.

>> можно на него переползать
> Можно, если время гробить не на что.

Да, в 12.04 время особо гробить не на что - все более-менее работает вроде.

>>проброс иксов есть
> Это как закажите. Со стразами али без...

Это что, нормальный фонт в браузере из коробки - уже за стразы считается? Да вы опупели.

> 12.04 уже стабилен можно на него переползать, проброс иксов есть ?
> как бем проброса иксов ? vnc ?

У меня на выданном ноуте 12.04 глючит изрядно, но Х через сеть вполне работают.

Лучше б сделали наоборот — к Unity2D прикручивали композитные эффекты и пилили дальше. Она меньше глючит и меньше ресурсов требует. А в Unity3D Compiz, который архитектурно неисправим.

Поддерживаю! Ведь Unity 2D написан на Qt. А Qt по моему мнению мощнее GTK. :)

> Поддерживаю! Ведь Unity 2D написан на Qt. А Qt по моему мнению
> мощнее GTK. :)

Очень смешно.

> Поддерживаю! Ведь Unity 2D написан на Qt. А Qt по моему мнению
> мощнее GTK. :)

Серёга, твои одноклассники тебя обманули. На Qt написан KDE. Честно!

Википедия: "KDE Software Compilation (KDE SC) — свободная среда рабочего стола и набор программ от проекта KDE. До начала 2010 года была известна как KDE (сокращение от K Desktop Environment). Построена на основе кросс-платформенного инструментария разработки пользовательского интерфейса Qt." http://ru.wikipedia.org/wiki/KDE

А вы бы, прежде чем нести этот бред не относящийся к делу, погуглили бы для начала на чем написана Unity2d.
И открою тайну - на qt не только KDE основано. Вот честно. Razor qt есть такой. И две кучи программ.  

А вы что солите ресурсы на зиму?

> А вы что солите ресурсы на зиму?

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

Нет, судорожно ищем розетку.

Насчёт ARM особенно позабавило -- с учётом того, как там грустно смотрелся даже вполне двумерный второй гном в исполнении и обвязке Ubuntu 10.04.

> Насчёт ARM особенно позабавило -- с учётом того, как там грустно смотрелся
> даже вполне двумерный второй гном в исполнении и обвязке Ubuntu 10.04.

ALT смотрится веселей?

> Насчёт ARM особенно позабавило

А мне кажется, что когда приходится обгаживать конкурента вместо того чтобы просто показать свои достижения - это как-то очень уж пахнет get the facts'ами.

>> Насчёт ARM особенно позабавило
> А мне кажется, что когда приходится обгаживать конкурента

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

> вместо того чтобы просто показать свои достижения - это как-то очень уж пахнет
> get the facts'ами.

Свои в работе (пока разве что чрутами под armv5 могу поделиться), а у альтов с год как есть пробный Office Server, работающий на плагах: http://www.altlinux.org/Ports/arm/officeserver

Но чтоб Вас так не расстраивать -- пожалуйста: http://fly.osdn.org.ua/~mike/img/screenshots/altlinux-arm-a5...

Единственно годное творение каноникал выкинуло, юнити 3д греет видюху, что аж руки жгет (у меня ноут) и видео притормаживает

> Единственно годное творение каноникал выкинуло, юнити 3д греет видюху, что аж руки
> жгет (у меня ноут) и видео притормаживает

У меня нетбук на процике от AMD со встроенной видяшкой, так он холодный, пока флеш на ютубе не запустишь. Full HD притормаживает, но остальное вполне себе играет.

> юнити 3д греет видюху,

Чего бы ради? У вас что за видяха? Power management включен?

nvidia g105m

многие пригодные для десктопа ARM-системы имеют встроенный 3D акселератор, почему они собираются игнорировать это? почему нельзя отключить эффекты или упросить их?

KMS DRM и прочее им надо для нормальной работы? ну так проще же тогда обойти применение того что нет в проприетарных дровах чем пытаться натягивать софтовый рендеринг

надеюсь Марк знает что делает, не перехитрили ли они сами себя?

> надеюсь Марк знает что делает, не перехитрили ли они сами себя?

Марк знает, как выпускать ОС для мазохистов.

> Марк знает, как выпускать ОС для мазохистов.

Очередной get the facts. И факты как обычно жареные.

>> Марк знает, как выпускать ОС для мазохистов.
> Очередной get the facts. И факты как обычно жареные.

Да хорошая твоя священная убунточка, хорошая, успокойся уже.

> многие пригодные для десктопа ARM-системы имеют встроенный 3D акселератор, почему они собираются игнорировать это?

не распарсил - кто и что игнорирует ?

> KMS DRM и прочее им надо для нормальной работы? ну так проще же тогда обойти применение того что нет в проприетарных дровах

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