Кто идет на Unix-way (или пользователь Linux - кто он)

[watashiwa_daredeska]

/me пошел еще раз гуглить про юникс-вей почему он не может быть совместим с гуи.

Потому что GUI проблематично подать на вход другой программе. Сравните:
1. Программа пишет логи в файл обычным plain-text. Можно применять весь арсенал средств для обработки текстов: grep, sed, awk и пр., представить кратки результат в агрегированном нужным нам образом виде. Причем: a) независимо от программы, b) весь арсенал уже существует и разработчику программы не нужно парить этим себе мозг.
2. Программа пишет логи в окошко. Красиво, разноцветно и т.п. Никаких готовых средств для обработки не существует, пользователь не может сделать с этой кашей ничего, кроме как тупо пялиться, как баран, в это дурацкое окошко.
Поэтому GUI — это финал обработки (или финал побочной ветви), способ отображения информации исключительно для человека.

[watashiwa_daredeska]

- пользователю используй то приложение которое позволит выполнить необходимую функцию за минимальное количество телодвижение (в идеале один клик или нажатеие энтера). Естественно без потери качества.

Каждое новое приложение — новая сущность, которая приводит к усложнению. Если задача решается за 5–10 минут однострочником на sh, то так и надо решать. При необходимости, решение можно записать в скрипт. Новое приложение стоит использовать только в том случае, если оно даёт какой-то ощутимый выигрыш.

[YUKLA]

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

Понимаете ли, коллега...

Мои статьи опубликованы в журналах. Глянцевых таких. В профильных изданиях. Их вычитывал сперва технический редактор. Потом - литературный. 3-4 раза каждую статью. Процесс правки был очень острым и жестким - как оно обычно и бывает. Так что реклама в статье - допустимая. Да, и учтите - статья не коммерческая, т.е., не я платил за публикацию, а мне платили. И просили продолжить цикл. Это просто к слову.

Что касается лично вашей вычитки. Вы просто не в теме. Увы.
1. Да. Большинство руководителей предприятий и не догадывается, сколько денег жрет IT и обоснованы ли расходы на его содержание. Хотите - приведу штук 20 пруфлинков на аналогичные статьи, в том числе и англоязычные? Это будет только капля в море. Или проще - почитайте базовые положения ITIL.

2. Да. Процесс расчета TCO сложный. Это ведь стандартный алгоритм. И простому бухгалтеру TCO не посчитать. Да и сисадмину не посчитать.

3. Да. Для СТАНДАРТИЗАЦИИ рассчета TCO существуют сертифицированные Gartner Group (аффтор TCO) программы.

4. Да. Для рассчета TCO Gartner Group рекомендует привлекать СТОРОННИЕ группы профессионалов. Потому, как бухгалтер и сисадмин вместе будут покрывать свое воровство, перерасход и прочие типичные для сервиса прелести. А так же - скрывать остановы и сбои оборудования. И свое неумение их прогнозировать. И отсутствие реальной стратегии борьбы с IT-рисками.

И так далее.

В общем - "Учиться, учиться и еще раз учиться!" © В.И.Ленин

[Voral]

Потому что GUI проблематично подать на вход другой программе. Сравните:
1. Программа пишет логи в файл обычным plain-text. Можно применять весь арсенал средств для обработки текстов: grep, sed, awk и пр., представить кратки результат в агрегированном нужным нам образом виде. Причем: a) независимо от программы, b) весь арсенал уже существует и разработчику программы не нужно парить этим себе мозг.
2. Программа пишет логи в окошко. Красиво, разноцветно и т.п. Никаких готовых средств для обработки не существует, пользователь не может сделать с этой кашей ничего, кроме как тупо пялиться, как баран, в это дурацкое окошко.

1. Гуевая программа может принимать параметры
2. Гуевая программа может давать нечто на выходе (да и в процессе)

Все зависит от разарботчика данной программы.

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

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

Т.е. использование такого софта уже не юникс вей......

А чем отличается GUI от TUI?
Тогда и Vim не юникс вей....... Так же можно ск онсольными командами поизвращаться....

Ну а GIMP зачем..... есть же imagemagic.........

- пользователю используй то приложение которое позволит выполнить необходимую функцию за минимальное количество телодвижение (в идеале один клик или нажатеие энтера). Естественно без потери качества.
Каждое новое приложение — новая сущность, которая приводит к усложнению. Если задача решается за 5–10 минут однострочником на sh, то так и надо решать. При необходимости, решение можно записать в скрипт. Новое приложение стоит использовать только в том случае, если оно даёт какой-то ощутимый выигрыш.

Хм. Да?
Ок. Вот статья
Задача "определить суммарный размер файлов в дереве каталогов"
"решается за 5–10 минут однострочником":

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

find -type f -print0 | xargs -0 cat | wc

Да, но есть правило: "Одна задача — одна программа"
и есть команда du.
Но ведь команда это и есть утилитка.... Которая обходит каталоги, смотрит размер и складывает...... Нафига ее сделали.

Где грань?
А если человек (утрировано) делает 90% времени одну и ту же задачу (только для примера): кодирует фильм из avi в 3gp, очищает RW диск и записывает туда данный фильм. Одной строкой сделать можно? (Думаю ни чего сложного)

Кто то сделает утилиту (даже консольную) которой на вход даешь ави файл. А она кодирует из ави в 3гп, очищает диск и записывает..... - "одна задача одна команда".....



зы Имхо любую идею можно фанатизмом загубить и исковеркать

[YUKLA]

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

Т.е. - Unix-way - это "внутренний", философский путь? Или таки, путь "потребителя"?

Проблема данной дискуссии как раз и заключается в том, что никак не удаётся договориться о терминах. Ув. t.t считает Unix-way путем самосовершенствования, вы упираете на то, что все это сделано для свободы использования... Все это очень разрозненно и смутно. И очень странно, что сами последователи Unix-way не могут чётко сформулировать ни парадигму, ни концепцию их пути. Ни, тем более - его привлекательность.

Что же касается "правил игры" - они есть в любой системе. Любая система, в конечном итоге, является набором некоторых стандартных программ, выполняющих узкоспециализированные функции. Обмен данными между таким программами тоже стандартизован. И в тоже есть возможность переправить вывод одной программы на ввод другой. Через те же pipes. Pipes API есть и в Win32 API, и в OS/2 API, и в Unix API. Когда вы выполняете перенаправление вывода программы на вход другой в командной строке - вы открываете соотв. pipe. Не вы лично, процесс скрыт от вас, но тем не менее. Есть и другие механизмы, перечисление которых займёт не одну страницу.

[Voral]

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

упс.... сначала както по диагонали прочитал данную фразу

Ну, а как оценить этот ощутимый выигрыш?

Давайте возьмем простейший пример. Архивирование.
1. Человек архивирует 1 раз в год или даже реже.
1.1 Каждый раз лезет в маны (ну или --help) посмотреть какую команду вводить. потом набирает это в консоли. Итого две команды.
1.2 Запукает некую утилиту с интерфейсом (не важно графика или текст). И просто ставит нужные галочки рядом. Все.
2. Человек пользуется архиватором ежедневно
2.1. Уже просто автоматом ставит нужные ключи
2.2. Аналогично первому человеку

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

[watashiwa_daredeska]

Если его задача тупо

Для «тупо» Unix-way не нужен. Выше уже говорилось, зачем он нужен.

1. Гуевая программа может принимать параметры
2. Гуевая программа может давать нечто на выходе (да и в процессе)

А при чём тут GUI? Получается, что GUI тут сбоку прилеплен, для красоты. Примерно так, как если бы к cp приделали графический «градусник».

Теоретически можно с базой работать с консоли..... Т.е. все обрабатывать и вводить и т.п. Только вот насколько это удобно?

Именно с 1С — не знаю, а вообще с БД это довольно удобно.

Тогда и Vim не юникс вей...

Не Unix-way, но никто и не говорил, что Unix-way — это Горец, который должен остаться один.

Ну а GIMP зачем...

См. про Vim.

Да, но есть правило: "Одна задача — одна программа"

Такого правила нет. Есть правило: «Одна программа — одна задача».

и есть команда du.

Команда du имеет существенные преимущества, по сравнению с Вашим скриптом:
1. Время работы du зависит от числа файлов, а не от их размера.
2. du умеет считать размер с учетом особенностей их размещения на HDD: блочная структура, «дырявые» файлы, ...

[Boboms]

Понимаете ли, коллега...

Мои статьи опубликованы в журналах. Глянцевых таких. В профильных изданиях. Их вычитывал сперва технический редактор. Потом - литературный. 3-4 раза каждую статью. Процесс правки был очень острым и жестким - как оно обычно и бывает. Так что реклама в статье - допустимая. Да, и учтите - статья не коммерческая, т.е., не я платил за публикацию, а мне платили. И просили продолжить цикл. Это просто к слову.

Что касается лично вашей вычитки. Вы просто не в теме. Увы.
1. Да. Большинство руководителей предприятий и не догадывается, сколько денег жрет IT и обоснованы ли расходы на его содержание. Хотите - приведу штук 20 пруфлинков на аналогичные статьи, в том числе и англоязычные? Это будет только капля в море. Или проще - почитайте базовые положения ITIL.

2. Да. Процесс расчета TCO сложный. Это ведь стандартный алгоритм. И простому бухгалтеру TCO не посчитать. Да и сисадмину не посчитать.

3. Да. Для СТАНДАРТИЗАЦИИ рассчета TCO существуют сертифицированные Gartner Group (аффтор TCO) программы.

4. Да. Для рассчета TCO Gartner Group рекомендует привлекать СТОРОННИЕ группы профессионалов. Потому, как бухгалтер и сисадмин вместе будут покрывать свое воровство, перерасход и прочие типичные для сервиса прелести. А так же - скрывать остановы и сбои оборудования. И свое неумение их прогнозировать. И отсутствие реальной стратегии борьбы с IT-рисками.

В общем - "Учиться, учиться и еще раз учиться!" © В.И.Ленин

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

1. Приведите, пожалуйста. Только Российских. Читайте итил сами (с таким же успехом Кира Булычева) - это биллитристика, не более того. Напоминаю, есть реальные условия бизнеса (о которых вы не совсем в курсе )

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

3. Не для стандартизации, а для поднятия бабок. В этом вся суть.

4. Э-э-э-э... Мне ясно, что вы имеете очень посредственное отношение к "практике", иначе не писали бы такую пургу. Вы хоть отвлеченно можете представить ситуацию, когда (!!) аудит выявляет все косвенные затраты? В нашей специфике?

[watashiwa_daredeska]

Ну, а как оценить этот ощутимый выигрыш?

Это субъективно и оценивается самим человеком.

[YUKLA]

/me пошел еще раз гуглить про юникс-вей почему он не может быть совместим с гуи.

Потому что GUI проблематично подать на вход другой программе. Сравните:
1. Программа пишет логи в файл обычным plain-text. Можно применять весь арсенал средств для обработки текстов: grep, sed, awk и пр., представить кратки результат в агрегированном нужным нам образом виде. Причем: a) независимо от программы, b) весь арсенал уже существует и разработчику программы не нужно парить этим себе мозг.
2. Программа пишет логи в окошко. Красиво, разноцветно и т.п. Никаких готовых средств для обработки не существует, пользователь не может сделать с этой кашей ничего, кроме как тупо пялиться, как баран, в это дурацкое окошко.
Поэтому GUI — это финал обработки (или финал побочной ветви), способ отображения информации исключительно для человека.

Вы заблуждаетесь. Радикально.
1. "Программа GUI" может использовать все существующие в API механизмы. И "трубки" - pipes, и "очереди" - queues, и просто соединения через TCP/IP Localhost. И так далее. Список механизмов точно такой же, как и для ЛЮБОЙ ДРУГОЙ ПРОГРАММЫ для данной операционной системы.
2. Алгоритм обработки текста НЕ ЗАВИСИТ от способа его хранения. Это аксиома. Странно читать это то вас, честное слово.
3. Не уж то вы полагаете, что алгоритмы, реализованные в "grep, sed, awk и пр" настолько уникальны, что нигде больше не применяются? Может быть, вам стоит начать с изучения текстовых функций базовых библиотек? Например - glib.
4. GUI - это GUI. Это просто библиотека для отображения информации по-пиксельно. А не по-символьно. Только и всего.

4. Э-э-э-э... Мне ясно, что вы имеете очень посредственное отношение к "практике", иначе не писали бы такую пургу. Вы хоть отвлеченно можете представить ситуацию, когда (!!) аудит выявляет все косвенные затраты? В нашей специфике?

17 лет практики в сетях 1500+ вас устроит? Вы, пожалуйста, детский сад кончайте. И почитайте то, что вам предлагает профессионал.
Простите, но вы еще в школу ходили, когда я первый стоечный сервер разворачивал.

ЗЫ: Честное слово - ожидал большего профессионализма для данного форума.

[Ali1]

Что касается лично вашей вычитки. Вы просто не в теме. Увы.

Позвольте вмешаться в вшиу перебранку.

1. Да. Большинство руководителей предприятий и не догадывается, сколько денег жрет IT и обоснованы ли расходы на его содержание. Хотите - приведу штук 20 пруфлинков на аналогичные статьи, в том числе и англоязычные? Это будет только капля в море. Или проще - почитайте базовые положения ITIL.

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

2. Да. Процесс расчета TCO сложный. Это ведь стандартный алгоритм. И простому бухгалтеру TCO не посчитать. tongue.gif Да и сисадмину не посчитать.

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

3. Да. Для СТАНДАРТИЗАЦИИ рассчета TCO существуют сертифицированные Gartner Group (аффтор TCO) программы.

В России действует национальное законодательство и "обычаи ведения дел".

4. Да. Для рассчета TCO Gartner Group рекомендует привлекать СТОРОННИЕ группы профессионалов. Потому, как бухгалтер и сисадмин вместе будут покрывать свое воровство, перерасход и прочие типичные для сервиса прелести. А так же - скрывать остановы и сбои оборудования. И свое неумение их прогнозировать. И отсутствие реальной стратегии борьбы с IT-рисками.

Вполне логично, но требует экономического обоснования для конкретного случая.

ИМХО Следовало бы объявить необходимые для проведения расчетов условия. Например, таким условием является: наличие достоверного и очень подробного аналитического учета соответствующих видов деятельности, правильную и непротиворечивую его группировку по экономическим категориям, обоснованность такой группировки.
Вы же приходите после падения сервера и нечто считаете. Что?

[watashiwa_daredeska]

бухгалтер и сисадмин вместе будут покрывать свое воровство

Воровство бухгалтера не имеет отношения к TCO отдела ИТ. Воровство админа, по Вашей же статье, включено в TCO.

А так же - скрывать остановы и сбои оборудования.

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

И свое неумение их прогнозировать. И отсутствие реальной стратегии борьбы с IT-рисками.

А это уже не про TCO совсем.

Итого, TCO считается очень просто — это суммарный бюджет отдела ИТ: зарплаты, оборудование, содержание офиса, воровство, неэффективность — всё тут. Плюс расчет стоимости сбоев и простоев, но это само по себе отдельная задача.

А расписывание по отдельным полочкам — это уже не расчет TCO, это аудит и оптимизация.

[Voral]

Для «тупо» Unix-way не нужен. Выше уже говорилось, зачем он нужен.

Не надо цепляться к словам. Можете поставить вместо "тупо" слово "только".

А при чём тут GUI? Получается, что GUI тут сбоку прилеплен, для красоты.

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

Именно с 1С — не знаю, а вообще с БД это довольно удобно.

Не надо? Кому удобно? Вам как разработчику БД? Да согласен. Что то менять, делать какие то разовые выборки... Точнее не так. Разовые вставки и обновления. Выборки нет. Делаем выбор из таблицы. Нужны все 20 столбцов. Сейчас я хочу отсортировать по столбику имя, теперь я хочу отсортировать по стобику дата.... и т.п.

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

Я может слишком чайник, но для таких вещей пользуюсь ibexpert'ом (база фаерберд под офтопиком) или phpmyadmin для мускуля. К тому же в базе например пару сотен таблиц. К сожалению не у всех память настолько хорошая да и разработчик(именно людей) может быть иной или их несколько. Каждый раз запрашивать список таблиц? Ню.... Ню....

Ну а для простых операций таки да с консоли удобно.

Такого правила нет. Есть правило: «Одна программа — одна задача».

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

[watashiwa_daredeska]

1. "Программа GUI" может использовать все существующие в API механизмы. И "трубки" - pipes, и "очереди" - queues, и просто соединения через TCP/IP Localhost. И так далее. Список механизмов точно такой же, как и для ЛЮБОЙ ДРУГОЙ ПРОГРАММЫ для данной операционной системы.

Может, но не делает. Вот ваша эта sysinfo. У меня N машин, я хочу сложить в БД описание их железячной части, чтобы иметь возможность анализировать. Сложить очень простым способом: hostname:type:model. Как я сделаю это с помощью Вашей программы?

2. Алгоритм обработки текста НЕ ЗАВИСИТ от способа его хранения. Это аксиома. Странно читать это то вас, честное слово.

Алгоритм не зависит, способ зависит.

3. Не уж то вы полагаете, что алгоритмы, реализованные в "grep, sed, awk и пр" настолько уникальны, что нигде больше не применяются? Может быть, вам стоит начать с изучения текстовых функций базовых библиотек? Например - glib.

Они не уникальны. Их удобно использовать. Для использования grep мне нужно набрать десяток символов, для использования glib мне нужно целый трактат на C написать, скомпилировать и т.п.

4. GUI - это GUI. Это просто библиотека для отображения информации по-пиксельно. А не по-символьно. Только и всего.

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

[YUKLA]

Воровство бухгалтера не имеет отношения к TCO отдела ИТ. Воровство админа, по Вашей же статье, включено в TCO.

"Бухгалтер" - это тот, кто подписывает IT-счета. И получает откаты. Наравне с.

А так же - скрывать остановы и сбои оборудования.

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

Еще раз - речь идет о ПОЛНОЙ оценке стоимости сбоя. Которая включает и недополученную прибыль, и потерю данных, и необходимость "срочной докупки" оборудования и так далее.

И свое неумение их прогнозировать. И отсутствие реальной стратегии борьбы с IT-рисками.

А это уже не про TCO совсем.

Итого, TCO считается очень просто — это суммарный бюджет отдела ИТ: зарплаты, оборудование, содержание офиса, воровство, неэффективность — всё тут. Плюс расчет стоимости сбоев и простоев, но это само по себе отдельная задача.

А расписывание по отдельным полочкам — это уже не расчет TCO, это аудит и оптимизация.

Вы статью то читали? Я же просил задавать вопросы. Мне кажется - вы там ничего не поняли.

"Бюджет" - это половина TCO. Остальное - сложный рассчет "непрямых" расходов. В которые, в том числе, входит и стоимость остановов и сбоев. Но не только она. А аудит информационной системы предприятия - это ОБЯЗАТЕЛЬНЫЙ этап расчета TCO. Первый, если быть точным.

Оптимизация - выводы и рекомендации по итогам TCO. Потому, как TCO дает осязаемый, видимый и понимаемый руководством предприятия срез затрат на содержание. И из итогов расчета TCO сразу становиться понятно, в чем лажает IT-отдел.

Именно по-этому часть сисадминов так люто ненавидит и ITIL и TCO.

[YUKLA]

Может, но не делает. Вот ваша эта sysinfo. У меня N машин, я хочу сложить в БД описание их железячной части, чтобы иметь возможность анализировать. Сложить очень простым способом: hostname:type:model. Как я сделаю это с помощью Вашей программы?

Я запланировал это сделать. Так и будет. Демоны на каждой из машин. И сбор информации по сети на рабочий компьютер администратора. Где будет гуёвая или html морда.
По примеру комплекса программ WhatsUp Gold. Посмотрите - интересная программа. Очень. Я ее эксплуатировал и очень доволен. Это - глобальный анализатор (в реальном времени) состояния всех сетевых устройств. Работает с принтерами, активным сетевым оборудованием, с серверами всех платформ и т.д. Агенты можно не ставить, есть поддержка SNMP.

3. Не уж то вы полагаете, что алгоритмы, реализованные в "grep, sed, awk и пр" настолько уникальны, что нигде больше не применяются? Может быть, вам стоит начать с изучения текстовых функций базовых библиотек? Например - glib.

Они не уникальны. Их удобно использовать. Для использования grep мне нужно набрать десяток символов, для использования glib мне нужно целый трактат на C написать, скомпилировать и т.п.

Нууууу..Написать и скомпилировать было бы не так сложно. Тут палка о двух концах. Немаловероятно, что функциями glib при умелом их применении те или иные задачи будет решены быстрее, чем шелл-скриптом. А то, что работать будет быстрее - так это 100 пудов.

4. GUI - это GUI. Это просто библиотека для отображения информации по-пиксельно. А не по-символьно. Только и всего.

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

Нет, вы опять путаете. Ваш текст - суть пикселы. И текст рисуют вам соотв. программы/модули/функции. Таким образом, вы получаете меньше степеней свободы. Чем если бы могли работать попиксельно.

Согласитесь, ПСЕВДО-графику придумали не от хорошей жизни.

Ну а хранение и обработка текста - это за гранью и CLI и GUI. Это просто данные в виде массива байтов.

[Voral]

И вообще мое ИМХО.

Большинство принципов Unix-Way именно и только для разработчиков. О чем, в общем-то, и говориться почти во всех статьях об этом пути. Применять их для пользователя это именно слепой фанатизм. Точнее даже на пользователя их только можно за уши притянуть.
Для пользователя можно применить только пару принципов:

Майк Ганцарз: Философия UNIX
Используйте программные рычаги для достижения цели.

ниже можно заменить "время программиста" на "Ваше время"

Реймонд: Искусство программирования в UNIX
Правило экономии: Время программиста дорого; сократите его, используя машинное время.

Что в итоге можно было для пользователя сформулировать типа:
"Цените свое время, выполняйте операции максимально удобным для Вас способом"

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

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

[watashiwa_daredeska]

Можете поставить вместо "тупо" слово "только".

Еще раз прочитайте, зачем нужен Unix-way. Если Ваши задачи можно перечислить, значит Unix-way Вам не нужен. Всё. Мои задачи перечислить нельзя.

Тем не менее "красивый" вывод информации это тоже задача.

Еще раз. Представление информации для пользователя лежит за пределами компетенции Unix-way. Unix-way — способ решения задач. Способ решения задачи в три действия абсолютно не связан с требованиями учителя по оформлению решения в тетрадке.

Что то менять, делать какие то разовые выборки...

Работать с БД в консоли удобно потому, что:
1. Я могу генерировать разные запросы к БД (хотя бы примитивной подстановкой параметров) в зависимости от... от чего захочу, от того и буду.
2. Я могу обработать текстовый вывод результата запроса средствами, не доступными в БД.
3. Я могу полученное решение своей задачи записать в скрипт и пользоваться им когда и как захочу: буду запускать руками в консоли, по расписанию из cron, встрою как команду в emacs и закреплю за горячей клавишей, ...

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

[watashiwa_daredeska]

"Бухгалтер" - это тот, кто подписывает IT-счета. И получает откаты. Наравне с.

Счета висят на балансе отдела ИТ, поэтому в бюджете отдела это будет учтено.

Еще раз - речь идет о ПОЛНОЙ оценке стоимости сбоя. Которая включает и недополученную прибыль, и потерю данных, и необходимость "срочной докупки" оборудования и так далее.

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

А аудит информационной системы предприятия - это ОБЯЗАТЕЛЬНЫЙ этап расчета TCO.

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

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

А, ну вот Вы и сами об этом сказали.

[YUKLA]

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

Нет. Читаем тут: 1, 2, 3, 4, 5, 6, 7.

Это не мои статьи. Это просто подборка. И не рекламирую я никого. Просто вы не понимаете основ методик управления информационными системами. По-этому, мне сложно вам что-то объяснить.

[watashiwa_daredeska]

Я запланировал это сделать. Так и будет. Демоны на каждой из машин. И сбор информации по сети на рабочий компьютер администратора. Где будет гуёвая или html морда.

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

В то же время, уже имеющимися средствами lspci|lsusb|/proc|hal|..., ssh и шелл-скриптинга я могу это сделать уже сегодня. Пусть не на 100%, но на 95% как минимум. И ради оставшихся процентов я вряд ли буду потом переделывать.

Нууууу..Написать и скомпилировать было бы не так сложно.

Это не сложно, это относительно сложно. Хотите сравнить?

Немаловероятно, что функциями glib при умелом их применении те или иные задачи будет решены быстрее, чем шелл-скриптом.

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

[diesel]

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

Т.е. - Unix-way - это "внутренний", философский путь? Или таки, путь "потребителя"?

не надо забывать о том что так или иначе мы говорим о техническом вопросе. А то "внутренний путь" - действительно напоминает об упомянутой sash-kan книге хотя становиться дзэн-буддистом для того чтобы следовать unix-way вовсе не обязательно (:

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

Проблема данной дискуссии как раз и заключается в том, что никак не удаётся договориться о терминах. Ув. t.t считает Unix-way путем самосовершенствования, вы упираете на то, что все это сделано для свободы использования...

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

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

Что же касается "правил игры" - они есть в любой системе. Любая система, в конечном итоге, является набором некоторых стандартных программ, выполняющих узкоспециализированные функции. Обмен данными между таким программами тоже стандартизован. И в тоже есть возможность переправить вывод одной программы на ввод другой. Через те же pipes. Pipes API есть и в Win32 API, и в OS/2 API, и в Unix API. Когда вы выполняете перенаправление вывода программы на вход другой в командной строке - вы открываете соотв. pipe. Не вы лично, процесс скрыт от вас, но тем не менее. Есть и другие механизмы, перечисление которых займёт не одну страницу.

существования возможности создания pipes в Windows .. ну хорошо, есть такая возможность. Что мне как пользователю, а не как разработчику это дает? я не могу сделать cat file.csv | msexcel.exe -e '{print $AAA}' or smth like. То что есть Стандарты обмена данными между программами - это конечно хорошо, но, их существование не дает пользователю ровным счетом ничего.

[Voral]

Еще раз прочитайте, зачем нужен Unix-way. Если Ваши задачи можно перечислить, значит Unix-way Вам не нужен. Всё. Мои задачи перечислить нельзя.

Блин.... Да что ж вы все так буквально воспринимаете..... Хорошо скажем так одна из многих миллионов задач. Это ни чего не меняет.
Еще раз и специально для вас объясняю точку зрения:
1. с точки зрения программиста (а именно с точки зрения и существует это понятие) все просто например в нашем споре. Разделить функционал и интерфейс.
2. для пользователя у него конкретная задача. И он должен ее сделать максимально просто. Конкретно он не не делает конвертирование без записи и без очистки...... И запись не делает без конвертирования. И отчистку диска не делает..... За то выполняет кучу других операций.
Почему не применим? Давайте ссылку? Какое количество задач считать переломным?

Опять же тот же случай c du. Его то же можно "разложить" на отдельные задачи.

Еще раз. Представление информации для пользователя лежит за пределами компетенции Unix-way. Unix-way — способ решения задач.

Ну и? Задача выводить на экран лог в реальном времени.

Работать с БД в консоли удобно потому, что:

Скажем так выполнять отдельные конкретные задачи. Полноценно работать с БД это вы загибаете - либо вы просто гений. Либо не очень много работаете с БД. Если бы я для каждого запроса писал бы скрипт то уже бы диска не хватило и идей по именованию. А сколько бы мусора накопилось........

[watashiwa_daredeska]

Нет, вы опять путаете. Ваш текст - суть пикселы. И текст рисуют вам соотв. программы/модули/функции. Таким образом, вы получаете меньше степеней свободы. Чем если бы могли работать попиксельно.

Это Ваш текст — суть пикселы. Мой текст — это суть символы. А уж как они отображаются и отображаются ли вообще — дело десятое.

Ну а хранение и обработка текста - это за гранью и CLI и GUI.

Это за гранью GUI, потому что GUI не имеет отношения к обработке. А CLI имеет отношение именно к обработке, а не к отображению.

[YUKLA]

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

В то же время, уже имеющимися средствами lspci|lsusb|/proc|hal|..., ssh и шелл-скриптинга я могу это сделать уже сегодня. Пусть не на 100%, но на 95% как минимум. И ради оставшихся процентов я вряд ли буду потом переделывать.

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

А так же - целый спектр ПО для управления сетевым аудитом оборудования и ПО, как от M$, так и от Novell, Cisco, Sun, IBM и так далее.
Перечислить? Это не считая прочих коммерческих программ...

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

Это - классическая отмазка. Не беспокойтесь. Я все закеширую. И вообще больше к диску обращаться не стану. Так что на определенном этапе я ваш скрипт обгоню 100 пудов.

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

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

[watashiwa_daredeska]

Хорошо скажем так одна из многих миллионов задач. Это ни чего не меняет.

Хорошо, скажем так: «Некоторые из моих задач можно перечислить и их можно решать вне Unix-way».

для пользователя у него конкретная задача. И он должен ее сделать максимально просто. Конкретно он не не делает конвертирование без записи и без очистки...... И запись не делает без конвертирования. И отчистку диска не делает..... За то выполняет кучу других операций.
Почему не применим? Давайте ссылку? Какое количество задач считать переломным?

Кто не применим? Unix-way? Для записи дисков? Очень даже применим. Я, например, так и писал. mkisofs bla-bla-bla | cdrecord bla-bla-bla. А то и вообще: tar c bla-bla-bla | gzip -9 | cdrecord bla-bla-bla. Конвертирование чего? Видео? Тоже можно — у меня где-то даже валялся скриптик, который перекодировал видео, подбирая параметры путем некоторых эвристик.

Ну и? Задача выводить на экран лог в реальном времени.

Это какая-то неправильная задача. less --follow-name +F её решает. Если же программа делает что-то полезное, то лог — вспомогательная задача. Тогда её надо ставить по другому: «выводить лог». Не на экран, а так, чтобы у пользователя было как можно больше возможностей этот лог обработать в своих целях.

Полноценно работать с БД

Это что?

[watashiwa_daredeska]

Во-первых, моя программа не дописана.

Это не меняет ситуацию в корне. Ваша программа выдает информацию, lspci, cat /proc/..., и прочие hal тоже выдают. Только вот, разработчикам этих программ не надо их дописывать, не надо никаких лишних демонов городить — уже можно собирать информацию способами, которые разработчики предполагать не могли. Более того, пока Вы не написали демона, я усложню Вам задачу: между машинами с которых информация собирается и машиной, на которую эта информация стекается, стоят брандмауэры, во все стороны, прямое соединение по IP невозможно, есть только ограниченный набор сервисов. В частности, почта. Или общедоступный файл-сервер.

Во-вторых - а что же до сих пор не сделали-то?

Я привел это как пример, близкий Вам. Я не админ, мне конкретно эта задача бесполезна совсем.

Не беспокойтесь. Я все закеширую. И вообще к диску обращаться не стану. Так что на определенном этапе я ваш скрипт обгоню 100 пудов.

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

SysInfo рекурсивно считает объем поддиректории от выбранной директории + вычисляет суммарный "шлак" (хвосты нераспределенных секторов).

«Дырявость» файлов учитывается? Считается ли суммарный выигрыш от «дыр»?

[watashiwa_daredeska]

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

Стандарты обмена дают очень даже много. Проблема-то как раз в том, что и в Windows можно написать program1 file | program2, только вот:
1. Инструментов в самой Windows ~0. Но можно поставить сторонние Cygwin, MSYS, ...
2. Хорошо, есть инструменты, но обрабатывать ими нечего, потому что «стандарта обмена данными» в Windows для этого не существует. В Unix стандартом является текст, и этот стандарт по возможности соблюдают. В Windows этот стандарт не соблюдают, как правило, даже тогда, когда можно бы.
3. В отличие от Unix, оконные приложения в Windows — это совсем совершенно другие приложения, чем консольные. Им по-умолчанию даже stdin, stdout, stderr не дают, даже если запускать из «командной строки».

[YUKLA]

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

Мне все равно. Это не усложнение задачи. Это уровень доступного транспорта. Реализовать отправку почты по протоколу SMTP не составит труда. Вообще говоря - информация может собираться и на промежуточной машине. С последующей отсылкой чего угодно куда угодно как угодно.

Посмотрите, все же, WhatsUp Gold. Там все это реализовано в полной мере.

Не беспокойтесь. Я все закеширую. И вообще к диску обращаться не стану. Так что на определенном этапе я ваш скрипт обгоню 100 пудов.

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

Я всего лишь отвечал вам по поводу "узких мест производительности". Скрипт хорош до определённого момента. Я и не отрицаю. Каждому инструменту свойственна своя область применения.

«Дырявость» файлов учитывается? Считается ли суммарный выигрыш от «дыр»?

"Дырявость" файлов не дает никакой экономии с точки зрения по-секторного хранения информации.

[Voral]

Хорошо, скажем так: «Некоторые из моих задач можно перечислить и их можно решать вне Unix-way».

раз уж вы меня отсылали на прочтение что такое и заче Юникс Вэй.
1. Процитируйте по которому пункту конкретно du проходит, а программа записи файла в нужном формате нет.
2. Где вообще говориться, что Юникс-Вэй это пользовательский вэй....

Я, например, так и писал. mkisofs bla-bla-bla | cdrecord bla-bla-bla. А то и вообще: tar c bla-bla-bla | gzip -9 | cdrecord bla-bla-bla.

Молодца.... Но я уже приводил пример про du. то что делает du можно разбить на отдельные задачи, на отдельные утилиты....

Ах да... du отрабатывает быстрее... А почему? Да потому что отброшен лишний функционал от алгоритмов тех утилит.... Так ведь и в моем примере можно причесать алгоритмы. И будет работать быстрее.

Тоже можно — у меня где-то даже валялся скриптик, который перекодировал видео, подбирая параметры путем некоторых эвристик.

Чем отличается ваш "скрипт" от "программы" имеющей тот же функционал?

Ну и? Задача выводить на экран лог в реальном времени.

Это какая-то неправильная задача. less --follow-name +F её решает.

Да решает. Теперь расскажите мне чем отличается визуальный вывод на консоль от вывода в графический интерфейс? Да ни чем. Только в графике можно больший объем отобразить. Да и глазу можно приятнее (или вы тот кто на юникс вэй обязан иметь схожие со всеми вкусы и любить исключительно текстовый вид или приведите ссылку опровергающую это).

Это что?

Выполнять те функции для чего разрабатывалась БД. Пример. Есть база объектов (людей, товаров... все равно). Каждый объект характеризуют порядка сотни параметров. Часть параметров прямо сидит в таблице этих объектов. Часть параметров находится в других таблицах и в первой только айдишники. А еще те параметры имеют свои параметры. И глубина может быть различна (теоретически до бесконечности). Но я сведу все до минимума

table1objects: id, name, cityid, typeid
table2city: id, name
table3type: id, name, groupid
table4grouptype: id, name
table5notes: id, datestart, datebegin, dateend,objectid

А теперь отберите мне быстро из консоли. Все объекты находящиеся в городе "Васильково", которые относятся по своему типу к группе толи "Неюниксоиды" толи "Лянуксы" толи еще как. (короче надо смотреть)( У тех у которых есть примечания которые действовали (не закрыты на текущую дату) с 01.12.2008.
Таблицы заполняете не только вы но и еще хотябы 30 человек..... К созданию структуры вы не причастны. Язык запросов не знаете. Рядом стоит живая очередь клиентов...... Структуры БД вы не знаете (хоть я ее вам и сказал), sql не знаете......... Основная ваша работа - работа с клиентами, работа с базой только инструмент.
Да даже если знаете язык запросов я вам буду искренне аплодировать если вы составите запрос с набором параметров быстрее, чем я в продуманном гуевом фильтре.