Великие мира сего спорят - почему Линукс успешен ?

> Вам для общения ещё и доп. окна нужны? Ну расскажите, зачем и как они сокращают усилия.

Если кто-то прислал мне сообщение, показывается автор и начало сообщения. Чтобы я постоянно не держал окно пейджера открытым.

> Сдается мне ,что реализация "недостающих" функций - дело недалёкого будущего.

Ага, ваши безграмотные пророчества, слава Богу, пока не сбылись. И не сбудутся. :)

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

Про убогую реализацию окон GIMP я уже писал. Перечитайте.

> Так "нравится с фанатиком" или "надоело читать охинею"?

Прикольно, но начинает надоедать. Пока желание не перешло в стадию скуки с покиданием этого топика. :)

> А про мой уровань уже было сказано-пересказано: оппонент, который постоянно обращает на это внимание ,заслуживает звание "сноб ЛОРа".

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

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

"А я люблю совать нос в чужие дела" (с) Шерлок Холмс. Предпочитаю истину доставать из споров - собеседник старается, я обучаюсь.

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

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

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

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

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

> Проще говоря, вы не могли объяснить того, почему в КДЕ не используется путь, описываемый в замечательносй саттье тов. Реймонда "Собор и Базар" (читали, нет?)

Читал. По организации KDE как раз вписывается в выводы (базарный способ разработки). По дроблению - тоже. Только вы зациклились на пайпах и CLI и не можете принять иные методы построения программ. Так что идеи Реймонда подтверждаются для KDE в полном объёме. :)

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

Уже который день пытаюсь до вас донести, что я не говорю про использование пайпов и консоли неопсредственно юзером. Я говорю про использование этих интсрументов _для построения приложения_. То есть построение архитектуры приложения на основе стандартных средств. Неужели я говорю так сложно, что вы не можете этого понять?

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

Примеров от вас я так и не дождался. Вы так до сих пор не показали, что конкретно не может сделать интератор для построения _любого_ приложения, входящего в состав KDE. Вы не показали необходимость KDElibs и KDEbase тем, что туда входят нестандартные средства. Правильная архитектура - первые версии Гнома. Гном - это всего лишь нахлобучка над теми стандартными средствами, которые он помогает связать воедино. Если бы не его реестр, построение новых велосипедов (типа наутилуса) и отсутствие тормозов, а также присутствие возможности более тесной интерграции приложений путем использования правильной архитектуры бакэнд-фронтэнд и преимущественное использование стандартных библиотек, то он был бы тем самым идеальным DE.

В KDE, вместо совершенствования и вылизывания стандартных средств необоснованно писались велосипеды, такие как Khtml, Kwin, DCOP, Kate (на собственном движке, несмотря на наличие Vim) и. т. д. Сейчас ошибки исправляются, но вы не видите, что то, о чём говорю я, это то, к чему идет KDE. И при этом отрицательно на это отвечаете. И это - борьба с пионерией, фанатизмом и т. д.? Кроме как провакацией это не назовёшь. И ладно бы, если это было ваше мнение, которое вы не разглашали. Так нет, таких как вас - тысячи (мягко намекаю на jackill), и они упорно не хотят понимать, что новые аппаратные средства - излишество при правильной архитектуре программ. В этом споре я ещё раз в этом убедился.

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

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

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

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

Конкретный пример - беспроблемное открытие архивов RAR и ZIP, созданных под Windows, с кириллическими именами файлов в архивах. Ну что, может?

> В KDE, вместо совершенствования и вылизывания стандартных средств необоснованно писались велосипеды, такие как Khtml, Kwin, DCOP, Kate (на собственном движке, несмотря на наличие Vim) и. т. д.

Приведите примеры полноценных замен Khtml, Kwin, DCOP, Kate на "стандартных средствах". Предлагаете пользователям осваивать дикие клавиатурные комбинации и убогий фолдинг vim?

> Так нет, таких как вас - тысячи (мягко намекаю на jackill), и они упорно не хотят понимать, что новые аппаратные средства - излишество при правильной архитектуре программ.

Молодой человек, когда вы напишите свою программу уровня KDE или хотя бы Kate и она будет востребована, то ваши иллюзии и заблуждения будут самому смешны. Пока что вы без опыта пытаетесь навязывать спорную концепцию повсеместно. И дальше лозунгов "правильности" и "стандартности" дело у вас не идёт. Жизнь гораздо многообразнее, но вы этого понять не можете.

> Короче говоря, мне очень хотелось бы узнать, чего нельзя сделать пайпами и консолью _в составе программы_ (то есть архитектура программы зиждется на них, а не включает как доп. функциональность), которую создал интегратор из стандартных юниховых средств.

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

Вот это флейм... и казалось бы - причем здесь Линукс... :)

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

Это ещё почему? Вы же сами приводили примеры на пайпах,как-то разбор html, сами сказали, как это реализовать, и что, интегратор не сможет сделать решение под задачу?

>Конкретный пример - беспроблемное открытие архивов RAR и ZIP, созданных под Windows, с кириллическими именами файлов в архивах. Ну что, может?

RAR-проприертарщина ,причём здесь OpenSource? Кроме того, эта задача явно про совершенство бакэнда. То есть если не может, то вы предпочитаете написать _монолитный_ велосипед, чем усовершенствовать существующий бакэнд?

Опять же, ЖДУ ПРИМЕР ЗАДАЧ, КОТОРЫЕ НЕЛЬЗЯ СДЕЛАТЬ ЧИСТО НА ПАЙПАХ И ПОЛУЧИТЬ ИНТЕГРИРОВАННЫЙ ПАКЕТ ПУТЁМ СКЛЕИВАНИЯ СТАНДАРТНЫХ СРЕДСТВ, НО КОТОРЫЕ РЕШАЮТСЯ С ИСПОЛЬЗОВАНИЕМ ВЕЛОСИПЕДОВ ТИПА dcop _БЕЗ_ ПРИМЕНЕНИЯ ПРИМЕРОВ, Б КОТОРЫХ РЕШАЮЩУЮ РОЛЬ ИГРАЕТ НЕ ТЕХНОЛОГИЯ (АРХИТЕКТУРА), НЕОДНОКРАТНО ПРИВОДИМАЯ МНОЙ, А СОВЕРШЕНСТВО БАКЭНДА (ИБО ЕГО МОЖНО УСОВЕРШЕНСТВОВАТЬ ИЛИ, В КРАЙНЕМ СЛУЧАЕ, ПИСАТЬ НОВЫЙ, А НЕ ВСТРАИВАТЬ ЕГО РЕАЛИЗАЦИЮ В МОНОЛИТ).

>Приведите примеры полноценных замен Khtml, Kwin, DCOP, Kate на "стандартных средствах".

Gecko (links, неплохой движок с плохим фронтэндом), FVWM2, pipe, vim. Удовлетворены? Gecko нужно усовершенисвовать, FVWM2 добавить возможность управлять профилями конфигов, pipe, vim...no comments. И всё это - вместо того, чтобы писать велосипеды.

>Предлагаете пользователям осваивать дикие клавиатурные комбинации и убогий фолдинг vim?

Нет, писать разработчикам _только _ фронтэнд, а не GUI + монолитную логику.

>Молодой человек, когда вы напишите свою программу уровня KDE или хотя бы Kate и она будет востребована, то ваши иллюзии и заблуждения будут самому смешны. Пока что вы без опыта пытаетесь навязывать спорную концепцию повсеместно. И дальше лозунгов "правильности" и "стандартности" дело у вас не идёт. Жизнь гораздо многообразнее, но вы этого понять не можете.

Обиделись?

Вообще-то всю жизнь были писатели, и были критики. И одни к другим одновременно имели большое и малое отношение. Тем не менее, одни без других не существуют и одни на других имеют довольно значительное влияние. Это раз. Эта "спорная концепция" - основа Unix систем. Существующая пришла из винды. И мне горько видеть, как из хорошей по архитектуре систему делают похожей на продукцию мелкософта. Это два. Я по образованию - не программист, поэтому хочу написать, но не могу. Это три. А программы с "правильной "архитектурой не будут востребованы также, как и виндовой, долгое время, ибо большинство сидит на виндах, и, переходя в линух, ищут такое же окружение, не всегда понимая и принимая идеи по эффективности использования. И в этом им помагают такие, как вы - пропагандисты винды на Linux'е в виде гнома и KDE. Это четыре.

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

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

>Надеюсь, вы удовлетворены ответом?

Я думаю ответ ясен, исходя из моих комментов ;)

P.S. Сдаётся мне, что всё получится, как это всегда бывает на лоре. Пока чего-то не реализовано, сторонники этого "чего-то" долго спорят про то, что это не нужно. Но чтоит появиться хотя бы альфа-версии нового продукта ьтак эти сторонники сразу берутся отсаивать точку зрения "видали, гады, и у нас это появилось". Как пример - ситуация с дефрагментатором. Вся ложь по поводу отсутствия необходимости в дефрагментации ФС стала всплывать лотько при появлении более-менее стабильных версий дефрагментаторов. До этого же - пужрили друг другу мозги и делали черезжопную cp source_1 source_2 && rm -rf * && cp source_2 source_1.

> Это ещё почему? Вы же сами приводили примеры на пайпах,как-то разбор html, сами сказали, как это реализовать, и что, интегратор не сможет сделать решение под задачу?

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

> RAR-проприертарщина ,причём здесь OpenSource? Кроме того, эта задача явно про совершенство бакэнда.

Ну, началось! RAR - это суровая правда жизни в email в России. Бэкенд тут не при чём - он тупо выдаёт в ibm866 (а в pkunzip - вообще в непонятной кодировке). Нужно универсальное решение перекодирования. Да и вы сами признали несовершенство бэкендов. Спрашивается - зачем использовать кривые стандартные инструменты?

> ЖДУ ПРИМЕР ЗАДАЧ, КОТОРЫЕ НЕЛЬЗЯ СДЕЛАТЬ ЧИСТО НА ПАЙПАХ И ПОЛУЧИТЬ ИНТЕГРИРОВАННЫЙ ПАКЕТ ПУТЁМ СКЛЕИВАНИЯ СТАНДАРТНЫХ СРЕДСТВ, НО КОТОРЫЕ РЕШАЮТСЯ С ИСПОЛЬЗОВАНИЕМ ВЕЛОСИПЕДОВ ТИПА dcop _БЕЗ_ ПРИМЕНЕНИЯ ПРИМЕРОВ

Тихо, тихо! Не кричите. Я уже написал, что нет таких задач. Сделать можно всё, но это будет очень дорого, поэтому никому и не нужно.

> Gecko (links, неплохой движок с плохим фронтэндом), FVWM2, pipe, vim. Удовлетворены?

Категорически нет! Текучка памяти, неповоротливость и привязка в GUI Gecko, слабая автоматизация FVWM2, поддержка только стандартных бэкендов с ограниченной функциональностью и невозможность рулить GUI, vim - вообще песня. Когда сделают нормально показываемый фолдинг и поддержку мыши - поговорим. Пока пользоваться им можно для крайне ограниченных задач.

> Нет, писать разработчикам _только _ фронтэнд, а не GUI + монолитную логику.

Давайте критерии "монолитности" в студию. А то мы, похоже, имеем разное представление о монолитности.

> И мне горько видеть, как из хорошей по архитектуре систему делают похожей на продукцию мелкософта.

Позвольте, KDE - лишь часть Linux. Можно всю жизнь проработать администратором в терминале (кстати, я с усмешкой смотрел, как "админы" в нашей конторе первое, что запускали - это deco на FreeBSD) и быть довольным. Не нравится KDE по архитектуре - не пользуйтесь. А кто-то доволен и KDE помогает выполнять его должностные обязанности эффективно.

> Я по образованию - не программист, поэтому хочу написать, но не могу.

Я вот по образованию - экономист. И нашёл, что программирование - не так сложно. Попробуйте. Неважно, с чего начнёте: bash, Python или KDE. Потом втянетесь. И опыт наработается.

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

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

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

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

> Код не улучшают, не пишут новый согласно архитектуре Unix, а пишут новый согласно архитектуре Windows.

Вы на Win32 API чистом писали? Я как раз писал. Поверьте, этот ужас ни капли не похож на тот же Qt/KDE или GTK+/Gnome.

Поймите, есть задачи и пути использования инструментария в них. Если для администрирования/быстрого просмотра кода достаточно консоли, то для офисной/домашней работы консоль - худший инструмент по эффективности. И не надо всех грести под одну гребёнку - ПО многообразно и не определяет архитектуру ОС. ОС - лишь прослойка между железом и процессами/файлами. И на этом уровне в Linux нет никакого копирования архитектуры Windows. Не надо путать идеи и реализации. :)

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

Почему, вместо того, чтобы {доделать, дописать, написать новые} консольные программы и сделать над ними фронтэнд, делают бекэнд как либы, а не как консольные приложения? Почему заново написанные инструменты разработчики KDE не пытаются позиционировать как новый стандарт, если это необходимо для замены старых/кривых инструментов, а собирают всё в один большой кусок аля KDElibs/Kdebase? Именно это можно назвать монолитом.

>слабая автоматизация FVWM2

Дописать, а не делать Kwin?

>Текучка памяти, неповоротливость и привязка в GUI Gecko

links?

>поддержка только стандартных бэкендов с ограниченной функциональностью и невозможность рулить GUI

Подробнее можно?

>vim - вообще песня. Когда сделают нормально показываемый фолдинг и поддержку мыши - поговорим.

Почему не доделали вим, а писали новый редактор?

>Давайте критерии "монолитности" в студию.

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

>Не нравится KDE по архитектуре - не пользуйтесь.

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

>И нашёл, что программирование - не так сложно.

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

>Может, рассмотрим парочку задач и сравним подбор инструментария, отбросив привычки?

Подготовка документации в техе (лучше в ликсе) и в ворде(аналоге)

мат. расчеты в мадкаде/матлабе и в максиме.

Прошу.

>Поймите, есть задачи и пути использования инструментария в них. Если для администрирования/быстрого просмотра кода достаточно консоли, то для офисной/домашней работы консоль - худший инструмент по эффективности. И не надо всех грести под одну гребёнку - ПО многообразно и не определяет архитектуру ОС. ОС - лишь прослойка между железом и процессами/файлами. И на этом уровне в Linux нет никакого копирования архитектуры Windows. Не надо путать идеи и реализации. :)

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

И отдельный пример: неиспользование, когда это возможно, довольно мощного ImageMagick.

> Почему, вместо того, чтобы {доделать, дописать, написать новые} консольные программы и сделать над ними фронтэнд, делают бекэнд как либы, а не как консольные приложения?

Потому что библиотеками удобнее пользоваться, передача параметров/результатов у них унифицирована (а не raw-поток, как в пайпах). Плюс к этому перехват ошибок удобнее.

> Почему заново написанные инструменты разработчики KDE не пытаются позиционировать как новый стандарт

Потому что соблюдают "чужие" стандарты (типа ODF, рекомендации RFC и т.п.). Проблемы фанатов консоли KDEшников ни в коей мере не волнуют.

> Дописать, а не делать Kwin?

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

> links?

Мда. Предлагаете вместо полноценного сёрфинга использовать ЭТО? Да вы шутник! :)

> Подробнее можно?

И снова по кругу! Кратко: невозможно задействовать всю мощь библиотек, только программы.

> Почему не доделали вим, а писали новый редактор?

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

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

Ну тогда под это определение подходят АБСОЛЮТНО ВСЕ программы, в том числе и консольные утилиты. Удивлены? :)

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

Ну как же?! А консоль? А FVWM? А Tcl? Что мешает имми пользоваться? Это же _правильные_, стандартные инструменты. А KDE - плохой, убогий, неправильный. Не пользуйтесь им! :)

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

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

> Подготовка документации в техе (лучше в ликсе) и в ворде(аналоге)

Какой документации? Книга, реферат, руководство, должностные инструкции?

> мат. расчеты в мадкаде/матлабе и в максиме.

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

> Причины отсутствия реализации бакэндов в виде консольных либ,

Что такое "консольная либа"?

> полная реализация в виде библиотек,

Про библиотеки уже писал. Вас не удивляет, что все консольные утилиты (тот же ImageMagic) используют свои библиотеки?

> и размещение этих библиотек в одном пакете,

А посмотреть было сложно? В любом пакете KDE (например, kdepim) помимо программ идут и специфические библиотеки.

> отсутствие позиционирования новых разработок как стандартов.

Уже писал - мы используем удобные технологии и стандарты. Зачем нам навязывать стандарты? Этим должны заниматься не разработчики, а специализированные комитеты. Вы этого не знали? :)

> И отдельный пример: неиспользование, когда это возможно, довольно мощного ImageMagick.

Он используется там, где нужно - в KOffice. В KDE нет смысла его использовать - слишком большой расход ресурсов для решения банальных задач со слабой управляемостью. :)

>Потому что библиотеками удобнее пользоваться, передача параметров/результатов у них унифицирована (а не raw-поток, как в пайпах).

Для унификации ч-либо можно использовать дополнительный уровень протокола передачи данных по пайпам. Что мешает? То есть данные передаются по пайпам, но обращаются к ним через либу, унифицирующую поток. Только не надо говорить, что это "через ж." на принципах абстракции от нижних уровней основан, к примеру, стек TCP/IP.

>Плюс к этому перехват ошибок удобнее.

Консольные проги трудно отлаживать?

>Потому что соблюдают "чужие" стандарты (типа ODF, рекомендации RFC и т.п.).

Что-то я мало вижу корреляцию между, к примеру, соблюдением ODF, и соблюдением стандартов Unix. А несоблюдение родных стандатов в одной системе по крайней мере странно.

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

Можно,к примеру, "автомобильные" части Kwin, по сравнению с велосипедом FVWM2? Только желательно широкоиспользуемые часли, а не узкоспециализировнные.

>Мда. Предлагаете вместо полноценного сёрфинга использовать ЭТО?

Есть претензии к уже написанной части движка?

>И снова по кругу! Кратко: невозможно задействовать всю мощь библиотек, только программы.

Я имел ввиду, почему стандартные бекэнды вдруг стали нелюбимы (почему нравится мода на нестандарт), и почему невозможно рулить GUI?

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

Допустим, но есть G/Kvim, GUI доделать нельзя? Даже если нельзя, почему не сделали Kate отдельно, как редактор на стандартных стредствах KDE, которые являются монолитом по анонимусу.

>Ну тогда под это определение подходят АБСОЛЮТНО ВСЕ программы, в том числе и консольные утилиты.

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

>Ну как же?! А консоль? А FVWM? А Tcl? Что мешает имми пользоваться?

Я говорил про отсутствие интегрирующей среды.

>А всё остальное - это прикладное программирование.

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

>Какой документации?

Любой, для которой можно написать стилевой файл. То есть любой, имеющей упорядоченную структуру.

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

Предложите свой вариант.

>Что такое "консольная либа"?

ДА, возможно тупое определение. Но это то, реализация чего возможна для консоли на 100 % . То есть любую функцию либ можно использовать в консоли.

>А посмотреть было сложно? В любом пакете KDE (например, kdepim) помимо программ идут и специфические библиотеки.

Прежде всего, я говорил про KDE{base,libs}

>Уже писал - мы используем удобные технологии и стандарты. Зачем нам навязывать стандарты?

Я не говорил про навязывание стандартов. Но разве хорошо, когда приложения Linux не имеют единого стандарта и каждая команда разработчиков пользуется тем, что считает удобным? Да, возможно это последствия базарного метода разработки, но это плохов конечном итоге сказывается на пользователях и архитектуре GNU/Linux в целом.

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

А использовать только либы?

P.S. Вообще, меня даже волнует не сколько архитектура, основанная на консольных программах, меня больше беспокоит то, что общего стандарта в Linux нет. Вы с этим согласны? Положительно к этому относитесь? (Напонму про QT, которую вы где-то не захотели считать за единственный стандарт, ибо концлагерь.) Команда KDE усугуьляет положение, как и комада гнома.

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

Тогда зачем нужны пайпы, если есть уже готовые сокеты? И унификация протокола через d-bus или DCOP? :)

> Консольные проги трудно отлаживать?

А при чём тут отладка? Речь идёт про исключения и разнообразные сигналы.

> Что-то я мало вижу корреляцию между, к примеру, соблюдением ODF, и соблюдением стандартов Unix.

Поймите, на Unix есть только один стандарт - POSIX, который соблюдается ядром и glibc. То, о чём вы говорите - лишь рекомендации, а никак не стандарты. :)

> Можно,к примеру, "автомобильные" части Kwin, по сравнению с велосипедом FVWM2?

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

> Есть претензии к уже написанной части движка?

Да. Нет полноценной поддержки CSS и JS. :)

> Я имел ввиду, почему стандартные бекэнды вдруг стали нелюбимы (почему нравится мода на нестандарт), и почему невозможно рулить GUI?

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

> Допустим, но есть G/Kvim, GUI доделать нельзя? Даже если нельзя, почему не сделали Kate отдельно, как редактор на стандартных стредствах KDE, которые являются монолитом по анонимусу.

Потому как идеология совершенно иная. Замучаешься интегрировать подход VIM и KatePart. Бред про монолит по анонимусу я уже прокомментировал.

> Нет. Стандартные консольные утилиты можно объединять с помощью конвейера.

KDEшные - тоже. И?

> GUI на стандатных средствах можно использовать (возможно, после доделки) для построения решений.

Пример?

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

То же самое касается и стандартных утилит.

> Опять же, аналогия с гномом: хорошая (возможно, избыточная, но хорошая) разбивка проекта на либы.

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

> Я говорил про отсутствие интегрирующей среды.

А как же Linux? :)

> Любой, для которой можно написать стилевой файл. То есть любой, имеющей упорядоченную структуру.

Опять пальцем в небо! Конкретно давайте.

> Предложите свой вариант.

Каталогизация фотографий. :)

> Прежде всего, я говорил про KDE{base,libs}

Там тоже не по одной библиотеке. Учите матчасть.

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

Все используют POSIX. Остальное - не стандарты.

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

Читайте про POSIX и перестаньте нести отсебятину.

>Тогда зачем нужны пайпы, если есть уже готовые сокеты? И унификация протокола через d-bus или DCOP? :)

Для связи с теми программами, которые не используют DCOP.

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

Про какие ошибки изначально шла речь?

>Поймите, на Unix есть только один стандарт - POSIX, который соблюдается ядром и glibc.

POSIX - стандарт "низкого уровня", описывает интерфейсные функции, он не учитывает архитектуру приложения и многие другие вещи. Кстати, там стандартным является Си. ;) То есть KDE в пролёте. А Tcl написан на Си => стандарт ;)

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

Такое может любой WM с поддержкой командной строки. Вызываете программу (KGet), после которой все другие окна получают другие атрибуты.

>Да. Нет полноценной поддержки CSS и JS. :)

Читайте по губам: _Есть ли претензии к _написанной_ части движка?

Дописать CSS и JS сложнее, чем написать Khtml?

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

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

>Потому как идеология совершенно иная. Замучаешься интегрировать подход VIM и KatePart.

А в чём проблема? Vim изначально совершеннее (во всяком случае, с подсветкой Tcl без помощи некоторых снобов у него всё в порядке), а необходимые фенечки реазизуются GUI.

>KDEшные - тоже. И?

Конвейер KDE менее стандартен, поддерживается только KDE.

>Пример?

Любая прога на TCL/Tk. Если необходимо доделать функциональность, включаете в пункт меню опцию, реазщизующуюся командой Tcl, которая связана со стандартными средствами.

>То же самое касается и стандартных утилит.

Но стандартные утилиты стоят на любой машине, так что "тянуть" как бы ничего и не надо.

>Этот ад библиотек уже притча во языцех. Уже все по этому поводу высказались, в том числе Торвальдс и Фолькердинг.

Это ад, но принцип лучше ,чем одна монолитная лиьа Kde. Сейчас часть библиотек засовывают в Gtk. Останется только то, что нужно - каждая либа дает свою функциональность, а не входит в монолит.

>А как же Linux? :)

GUI

>Опять пальцем в небо! Конкретно давайте.

Книга. Бланк. реферат.

>Каталогизация фотографий. :)

По какому признаку?

>Там тоже не по одной библиотеке. Учите матчасть.

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

>Все используюЧитайте про POSIX и перестаньте нести отсебятину.т POSIX. Остальное - не стандарты.

Про Posix уже было сказано. KDE ему не удовлетворяет в полной степени, ибо написан на C++.

> Для связи с теми программами, которые не используют DCOP.

Для связи между хостами тоже пайпы будете использовать? :)

> Про какие ошибки изначально шла речь?

Исключения во время работы программы. Например, отвалился хост или не найден файл в массовых операциях.

> Кстати, там стандартным является Си. ;) То есть KDE в пролёте. А Tcl написан на Си => стандарт ;)

POSIX не исчерпывается C. Так что учите матчасть.

> Такое может любой WM с поддержкой командной строки. Вызываете программу (KGet), после которой все другие окна получают другие атрибуты.

Ручками будете логику задавать? Демоном? Снова велосипеды? :)

> Читайте по губам: _Есть ли претензии к _написанной_ части движка? Дописать CSS и JS сложнее, чем написать Khtml?

Да, гораздо сложнее.

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

Я разве говорил про "консольный интерфейс над библиотекой". Уже бредите? И про пайпы - откровенный бред. Идите, мечтайте дальше.

> А в чём проблема? Vim изначально совершеннее (во всяком случае, с подсветкой Tcl без помощи некоторых снобов у него всё в порядке), а необходимые фенечки реазизуются GUI.

Куча фич Kate в vim не реализована. Да и с подсветкой/фолдингом Clipper в vim - полная труба. Так что не надо тут втирать про "совершенство".

> Конвейер KDE менее стандартен, поддерживается только KDE.

В чём разница между конвейером в KonsolePart и в командной строке?

> Любая прога на TCL/Tk.

Ага, и кому нужны эти жутко маргинальные программы? Судя по их количеству - только фанатикам вроде вас.

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

У меня Tcl нет, так как этот велосипед ни разу не стандартный инструмент. :)

> Это ад, но принцип лучше ,чем одна монолитная лиьа Kde.

Вы так и не смогли доказать монолитность KDE. Так что лучше молчите. :)

> Сейчас часть библиотек засовывают в Gtk.

Назовите хотя бы одну. :)

> GUI

Не могли найти графическую IDE под Linux? Очередной виток бреда? :)

> Книга. Бланк. реферат.

Вы можете перестать прыгать и вести себя по взрослому?

> По какому признаку?

По дате и тегам. С возможностью обработки.

> Про Posix уже было сказано. KDE ему не удовлетворяет в полной степени, ибо написан на C++.

Хватит устраивать детский сад! Сначала докажите, что KDE не использует ни одну из технологий, регламентированных POSIX. До тех пор буду считать вас болтуном.

>Для связи между хостами тоже пайпы будете использовать? :)

TCP/IP ?

>Исключения во время работы программы. Например, отвалился хост или не найден файл в массовых операциях.

Чем 2> не угодил?

>POSIX не исчерпывается C. Так что учите матчасть.

Posix зиждется на нём. Сами учите, особенно про стандартную libc.

>Ручками будете логику задавать? Демоном? Снова велосипеды? :)

Конфигом к программе, которая строит баш-скрипт с нужными параметрами. Эти "велоспеды" называются "интерфейс верхнего уровня". Именно уровневая архитектура применима в Unix, а не монолитная (во всех пониманиях). И уже многократно приводившийся пример - стек TCP/IP.

>Да, гораздо сложнее.

То есть напиать ядро Khtml, приделать к нему модули CSS и JS сложнее, чем просто приделать к готовому ядру links те же модули? Жжоте!

>Я разве говорил про "консольный интерфейс над библиотекой"

А вы где-нить видели консольные программы без библиотек, за исключением системных ,статично скомпилированных с libc, и некоторых простых?

>Куча фич Kate в vim не реализована.

И снова с нами "Поле Чудес", игра со зрителями. Вопрос: почему Kate написать проще, чем доработать vim и гуи над ним?

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

>Да и с подсветкой/фолдингом Clipper в vim - полная труба.

А в Kate полная труба с подсветеой тикля. И что? У каждого свои недостатки. Программисты должны окончательно чокнуться, чтобы писать новый редактор из-за отсутствия подсветки Clipper в старом.

>В чём разница между конвейером в KonsolePart и в командной строке?

Мы сейчас говорим про методы связи приложений, а не консоль. Хочу вывод cat в адресную строку завоевателя. К конвейером это бы выглядело где-то так: cat text.txt > konqueror -i adressline. Для dcop, если такое возможно, пришлось бы учить новый синтаксис.

>Ага, и кому нужны эти жутко маргинальные программы?

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

>У меня Tcl нет, так как этот велосипед ни разу не стандартный инструмент. :)

Стандартные утилиты - преже всего те, что стоят в /bin и /sbin. А про велосипед - аналоги его по функциональности будут? Python не предлагать - там даже нельзя команду автогенерировать.

>Вы так и не смогли доказать монолитность KDE.

Вы математику изучали? Разницу между определением и теоремой знаете? Судя по всему, нет. Я дал определение своего понимания монолитности. Фраза "Вы так и не смогли доказать монолитность KDE" глупа по всей своей сути.

>Назовите хотя бы одну. :)

http://www.linux.org.ru/view-message.jsp?msgid=1043964&page=0 http://live.gnome.org/ProjectRidley

Гугл надо уметь юзать...

>Не могли найти графическую IDE под Linux? Очередной виток бреда? :)

Причём здесь IDE?

>Вы можете перестать прыгать и вести себя по взрослому?

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

>По дате и тегам. С возможностью обработки.

"Вы можете перестать прыгать и вести себя по взрослому?" Мне ваши эти "дополнения" конкретно надоели. Говорите точно, сколько вешать в граммах? Поскольку ответ sort + ImageMagick вас наверняка не удовлетворит, и вы в этом сами виноваты, ибо не умеете формулировать задачу.

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

А почему я? Вы привели стандарт, вам и доказывать. Свои идеи про пайпы и архитектуру я наглядно предоставил. И вообще, вы слышали про "низкий уровень", о котором я упомянул? По-моему, нет. И ,сдаётся мне, что с таким мнением и FHS вы за стандарт не примете.

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

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

> TCP/IP ?

Нахватались умных слов? Что, TCP/IP на низком уровне? И как вы себе это без сокетов представляете? А если IPX в сети, а TCP/IP нет вообще? :)

> Чем 2> не угодил?

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

> Posix зиждется на нём. Сами учите, особенно про стандартную libc.

Неправда. C - лишь реализация механизмов и стандартов POSIX, а libc - обязательная библиотека. Говорить, что "зиждется" - очередной раз садится в лужу. :)

> То есть напиать ядро Khtml, приделать к нему модули CSS и JS сложнее, чем просто приделать к готовому ядру links те же модули? Жжоте!

Попробуйте, а потом удивляйтесь. :)

> А вы где-нить видели консольные программы без библиотек, за исключением системных ,статично скомпилированных с libc, и некоторых простых?

А при чём тут "консольные программы"? Зациклились? :)

> И снова с нами "Поле Чудес", игра со зрителями. Вопрос: почему Kate написать проще, чем доработать vim и гуи над ним?

Потому как подходы к редактированию разные. Поработайте в проектах - тогда не будете нести ахинею.

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

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

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

Ну я потратил немного усилий на доведение подсветки/фолдинга Clipper для Kate. А вопрос переписывания только плод вашего больного воображения.

> К конвейером это бы выглядело где-то так: cat text.txt > konqueror -i adressline.

konqueror `cat text`. :)

> Кривые руки программёров не делают тикль плохой средой разработки.

Маргинальный - значит "пограничный", невостребованный. Именно из-за синтаксиса и возможностей.

> Кстати, аналога в своей нише у тикля нет.

Полно! Kommander, PyGTK, PyQt. И удобно и функционально.

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

Я, в отличие от вас, претензии не предъявляю и фанатизмом не страдаю. Каждый инструмент имеет свою нишу. Какие-то - бОльшую, другие - меньшую. У Tcl, к примеру, маргинальная ниша. Поэтому весьма сомнительно навязывать на Tcl как на общеупотребимую платформу.

> Я дал определение своего понимания монолитности. Фраза "Вы так и не смогли доказать монолитность KDE" глупа по всей своей сути.

Увы, ваше определение касается любой программы. Поэтому тренируйте свой смысловой аппарат. :)

> Гугл надо уметь юзать...

И где там сказано, что KDEшники пишут библиотеки GTK+? :)

> Причём здесь IDE?

Согласен, немного ушёл в сторону. Имелось ввиду, что если нет аналога KDE на "правильных" инструментах - то IDE в зубы и вперёд. :)

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

Отнюдь. Все три можно создать. Причём на печать получим то, что требуется с минимальными усилиями. Ибо WYSWYG. На "стандартных инструментах" куда как больше трудозатрат (если не учитывать случаи подготовки научных статей).

> Поскольку ответ sort + ImageMagick вас наверняка не удовлетворит, и вы в этом сами виноваты, ибо не умеете формулировать задачу.

Просто вы не знаете, что такое "каталогизатор фотографий". Почитайте хотя бы http://www.compress.ru/Archive/CP/2004/11/6/, чтобы я не повторял очевидные истины. :)

> Вы привели стандарт, вам и доказывать.

Не я называл KDE нестандартным средством. :)

> Свои идеи про пайпы и архитектуру я наглядно предоставил.

Да, было. Правда, к реальной жизни они отношение не имеют. :)

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

Нет, доказывалось, что никто не хочет идти в описанный вами концлагерь. :)

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

Я на работу пешком хожу. И требования софта мне как-то "побарабану", ибо работает без проблем и на домашней машинке 2003 года и на ноутбуке 2006 года. Нет рефлексий по поводу "злого софта" -> нет и комплексов -> жизнь прекрасна. :)

>Нахватались умных слов? Что, TCP/IP на низком уровне? И как вы себе это без сокетов представляете? А если IPX в сети, а TCP/IP нет вообще? :)

Про какие хосты тогда идёт речь и какую роль там играет dcop?

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

Так и запишем: ниасилили регеспы.

>Неправда. C - лишь реализация механизмов и стандартов POSIX, а libc - обязательная библиотека. Говорить, что "зиждется" - очередной раз садится в лужу. :)

В этом и вся соль. libc - обязательная, на ней и должен строится интерфейс. А на чём строится он у КДЕ?

И вообще, бросьте вы этот POSIX. Русским же языком было сказано- низкий уровень. Для вас стандарты высокого уровня вроде FHS играют какую-либо роль?

>Попробуйте, а потом удивляйтесь. :)

Писать браузер с нуля? Одному? Вы с ума сошли.

>А при чём тут "консольные программы"? Зациклились? :)

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

>Поработайте в проектах - тогда не будете нести ахинею.

Давайте не путать текстовой редактор и IDE. Kate, кстати, до последнего не дотягивает только наличием поддержки проектов.

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

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

>Ну я потратил немного усилий на доведение подсветки/фолдинга Clipper для Kate. А вопрос переписывания только плод вашего больного воображения.

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

>konqueror `cat text`. :)

Вы где-нибудь видите здесь межпроцессное взаимодействие? Я нет. А мы говорим как раз о нём.

>Именно из-за синтаксиса и возможностей.

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

>Полно! Kommander, PyGTK, PyQt. И удобно и функционально.

Тикль - это Tcl, а не Tk (ти-кей) ( Вместе - так-тикль). Соглашусь, последний не очень красивый, но он удобный в применении и довольно функциональный.

Я говорю про замену тикля, а не ти-кея.

>Увы, ваше определение касается любой программы.

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

>Имелось ввиду, что если нет аналога KDE на "правильных" инструментах - то IDE в зубы и вперёд. :)

То есть стандартная отмаза - "Не нашёл? Напиши сам!", так что ли?

Кстати, ваши доводы за красивый интерфейс похожи на женскую логику. У них тоже есть что-то вроде "Если из P следует Q, и Q красиво,то P - истинно". Свою машину, если она у вас есть, конечно, вы скорее покрасите в красивый розовый цвет, а не будете ездить на драном с движком, который чуть ли не летать сможет.

>На "стандартных инструментах" куда как больше трудозатрат (если не учитывать случаи подготовки научных статей).

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

>Просто вы не знаете, что такое "каталогизатор фотографий". Почитайте хотя бы http://www.compress.ru/Archive/CP/2004/11/6/, чтобы я не повторял очевидные истины. :)

Прочёл. Средство аля создание БД и ФС из симлинков. Даже не знал, что над этим нужно строить гуи. И чего только люди не придумают, чтобы заставить компьютер разгребать собственноручно устроенную на винте помойку.

>Не я называл KDE нестандартным средством. :)

А я называл? Хотя это действительно так, я говорил лишь, что архитектура КДЕ не построена на стандартных средствах.

>Правда, к реальной жизни они отношение не имеют. :)

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

>Нет, доказывалось, что никто не хочет идти в описанный вами концлагерь. :)

А от того, что вас заставляют ГОСТы соблюдать, вам не кажется, что вы в концлагере? Ил в программах лучше сделать, как в русском языке - создать многосмыслие путё уничтодения всего, кроме POSIX?

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

>Нет рефлексий по поводу "злого софта" -> нет и комплексов -> жизнь прекрасна. :)

-У вас на стройке несчастные случаи были?

-Нет, пока ещё не было.

-Будут.

Подождите 5-10 лет, может поймете.

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

> Про какие хосты тогда идёт речь и какую роль там играет dcop?

Это было сказано к вопросу о том, что пайпами не ограничивается Unix. DCOP тут не при чём.

> Так и запишем: ниасилили регеспы.

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

> В этом и вся соль. libc - обязательная, на ней и должен строится интерфейс. А на чём строится он у КДЕ?

KDE использует Qt, которая, в свою очередь, использует libc. См. ldd /usr/bin/kate | grep libc\.

> Для вас стандарты высокого уровня вроде FHS играют какую-либо роль?

Конечно. Так как он входит в LSB. :)

> Писать браузер с нуля? Одному? Вы с ума сошли.

Нет, попробуйте привернуть CSS и JS к lynx/links. :)

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

http://developer.kde.org/documentation/library/3.5-api/kdebase-apidocs/kate/h...

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

Это была лишь одна из причин и не самая основная. Основная - неинтуитивность работы с VIM и слишком большое количество телодвижений при слабой визуализации. По поводу фолдинга: сколько строк вы писали в своих проектах, чтобы ставить под сомнение удобство фолдинга? И как он связан с рефакторингом? :)

> Вы где-нибудь видите здесь межпроцессное взаимодействие? Я нет. А мы говорим как раз о нём.

Так и не давайте глупых примеров, если не разбираетесь. RPC идёт через DCOP: `dcop konqueror-3148 konqueror-mainwindow#1 openURL http://www.ya.ru`

> А каких возможностей вам не хватает?

В плане GUI (Tk): удобства сигналов-слотов, политики растягивания с пружинами, отсутствие проблем с Unicode, разнообразные виджеты (sheet, db grid). Ну и напряги с явно раздутым кодом, производительностью и стилями виджетов напрягают. :)

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

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

Где он везде используется? Тот же tclsh и wish я запустил только один раз - чтобы посмотреть на это чудо. Не надо обобщать.

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

Красота - лишь один из элементов эргономики.

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

Помимо использования стилей, которые можно использовать и в WYSWYG, есть ошибки и в орфографии/компоновке. И оформление занимает всегда меньшую часть, чем собственно набор и компоновка текста.

> А от того, что вас заставляют ГОСТы соблюдать, вам не кажется, что вы в концлагере? Ил в программах лучше сделать, как в русском языке - создать многосмыслие путё уничтодения всего, кроме POSIX?

Нет, потому как ГОСТы достаточны для решаемых ими задач. "Стандартные" средства Unix, за которые вы ратуете - недостаточны для удобной работы с современными задачами.

> Кстати, судя по моему опыту, "никто" это бывшие вантузятники, не понимающие идею юних, и некая неклассифицирующаяся каста людей.

Отнюдь. Идеи Unix не нивелируются опытными пользователями. Как я уже говорил, для каждого инструмента есть задачи. И эти инструменты используются там, где надо. Например, я не полезу в консоль для уменьшения размеров выбранных в preview фотографий с заливкой их на CD. Digikam сделает это быстрее и нагляднее. С другой стороны, я предпочту просмотреть логи загрузки в консоли, а не в графической программе. Фишка в том, что с увеличением гибкости и функционала графический приложений консоль становится всё меньше нужна. Если во времена моего освоения Linux 6 лет назад GUI-приложения были откровенно убоги, то сейчас консоль остаётся как запасной вариант для администрирования и экзотических манипуляций.

> Подождите 5-10 лет, может поймете.

Уже 6 лет жду, а светлого беспроблемного будущего консоли не вижу. Она встраивается и используется всё реже (хотя Konsole у меня всегда запущен).

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

Объясните, зачем держать 100 открытых табов? Ниасилили закладки? :)

> Какие в таком случае могут быть жалобы с вашей стороны на современный софт?

У меня почти нет жалоб на современный софт. Есть некоторые шероховатости, но они недостаточны для полного перехода в консоль.

>Это было сказано к вопросу о том, что пайпами не ограничивается Unix. DCOP тут не при чём.

А кто говорил, что ппйпами ограничивается Linux? Я говорил лишь про межпроцессное взаимодействие.

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

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

>Конечно. Так как он входит в LSB. :)

Уже хорошо. Значит, стандарты повыше Posix интересуют. Теперь вопрос: зачем этот стандарт включает в себя многие консольные программы?

>http://developer.kde.org/documentation/library/3.5-api/kdebase-apidocs/kate/h...

Можно своими словами? Искать фичи и их соответствие движку нет никакого желания.

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

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

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

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

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

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

>политики растягивания с пружинами, отсутствие проблем с Unicode, разнообразные виджеты (sheet, db grid).

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

>В плане языка - раздутость кода IMHO

Раздутость языка - это нехватка возможностей ??? o_O Так все-таки тикль - достаточно функциональный, и, главное, незаменимый для своей области?

>Где он везде используется? Тот же tclsh и wish я запустил только один раз - чтобы посмотреть на это чудо. Не надо обобщать.

Ещё раз: я говорю про стандартные средства, а не про тикль, который стандарт де-факто, а не де-юре.

>И оформление занимает всегда меньшую часть, чем собственно набор и компоновка текста.

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

>Нет, потому как ГОСТы достаточны для решаемых ими задач.

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

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

Вы опять забываете, о чём идет речь. Я говорю о замене программиста интегратором при построении решения. Программист лишь участвует в написании "кирпичиков". К примеру, вашего любимого модуля CSS, который можно реализовать в виде стандартной либы и испльзовать в любом браузере. Вы лезете в чисто консоль.

>Уже 6 лет жду, а светлого беспроблемного будущего консоли не вижу.

Опять поняли всё не так. Я говорю про проблемы с софтом. Возможно, только тогда он покадется слишком прожорливым...;)

>Объясните, зачем держать 100 открытых табов? Ниасилили закладки? :)

Объясняю. Браузер открыт на:1. Поиск. 2. Готовая информация.

1. Это гугл. Я открываю гугл и, пролистывая 10-20 листов, набираю кучу полезных на мой взлгяд ссылок. Потом просматриваю их последовательно. Обычно набегает сотня-другая табов на окно. Таких окон у меня несколько. Сколько табов всего?

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

И, кроме того, у меня постоянно открыто окно с лором и несколькими другими сайтами, в том числе информационными. Это ок. 20 табов.

Считать табы умеете? ;)

P.s. Прошу прощения за возможно корявые ответы - очень напряжённые дни пошли, нет времени на лучшее ;)

> А кто говорил, что ппйпами ограничивается Linux? Я говорил лишь про межпроцессное взаимодействие.

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

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

Как раз пайпы - это элементарщина. Дальше примитивной обработки больших текстовых данных они не годятся.

> Теперь вопрос: зачем этот стандарт включает в себя многие консольные программы?

Для минимально возможной работы. В своё время на SCO Unix я столкнулся со случаем, когда нужно было поправить конфигурацию, а vi и других редакторов не было. Пришлось выкручиваться sed'ом. :)

> Можно своими словами? Искать фичи и их соответствие движку нет никакого желания.

Вся обработка текста: курсоры, замена и прочее.

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

Слишком большой расход времени с минимальной отдачей для нетривиальных задач.

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

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

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

Потому как даже при разбивке на модули файлы содержат очень много структур. Можно легко потеряться. Попробуйте полноценно работать с файлами исходников на пару тысяч строк кода - поймёте. В команде Eclipse и MSVS дураки сидят, ага! :)

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

Ага, а links stderr не поддерживает и невозможно в запущенном экземпляре открыть URL. Хреновое межпроцессное взаимодействие.

> С уникодом проблем нет - тикль реализовал его давно.

Ага, в заголовках окон только билиберда. Локаль юникодная.

> "разнобразные" виджеты реализуются сторонними средствами и постепенно переходят в основной проект. BrWidget, например.

Слишком медленно и слишком мало виджетов. Для простого интерфейса годятся, до Qt сильно не дотягивают. :(

> Раздутость языка - это нехватка возможностей ???

Это слабая эффективность. :)

> Так все-таки тикль - достаточно функциональный, и, главное, незаменимый для своей области?

Ну и где его область применения? :)

> Ещё раз: я говорю про стандартные средства, а не про тикль, который стандарт де-факто, а не де-юре.

Вот я и спрашиваю: если он стандарт де-факто, то почему нигде не используется? :)

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

Он не мой любимый, он ваш любимый. :) Вы пытаетесь перетащить всех в консоль и Tcl/Tk, я же категорически против этого.

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

Не задумывались, почему никто это ещё не написал? :)

> Возможно, только тогда он покадется слишком прожорливым...;)

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

> 1. Это гугл. Я открываю гугл и, пролистывая 10-20 листов, набираю кучу полезных на мой взлгяд ссылок.

Не умеете писать запросы в Google, чтобы выдало то, что нужно? :) мне обычно дальше 5 листа не нужно.

> Обычно набегает сотня-другая табов на окно. Таких окон у меня несколько. Сколько табов всего?

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

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

Читайте медленно? Ваши проблемы. :)

> И, кроме того, у меня постоянно открыто окно с лором и несколькими другими сайтами, в том числе информационными. Это ок. 20 табов.

Про RSS слышали? :)

> Считать табы умеете? ;)

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

> P.s. Прошу прощения за возможно корявые ответы - очень напряжённые дни пошли, нет времени на лучшее ;)

Я заметил - и браузер у вас без подсветки ошибок и тысяча табов открыты. :)

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

Я и говорю про частный случай, а именно про тот, где он использовался ранее в самой Unix.

>Как раз пайпы - это элементарщина. Дальше примитивной обработки больших текстовых данных они не годятся.

Что самое интересное - большинство задач - это текст и его обработка. Игры и графика - исключение. Что остаётся? Сеть, текст, наука, почта, средства общения...- всё текст. Зачем что-то ещё?

>Для минимально возможной работы. В своё время на SCO Unix я столкнулся со случаем, когда нужно было поправить конфигурацию, а vi и других редакторов не было. Пришлось выкручиваться sed'ом. :)

vi, насколько я знаю - стандарт, так что не совсем в тему. К тому же, к примеру, bash или его более компактные собратья способны на "минимальную работу", тем не менее awk тоже стандарт. Нафиг?

>Вся обработка текста: курсоры, замена и прочее.

Замена плохо реализована в vim'е? А курсоры относятся к логике?

>Слишком большой расход времени с минимальной отдачей для нетривиальных задач.

Так в основном на компьютере решаются тривиальные задачи. К примеру, набот ткеста или счет в таблицах. Тем не менее, многие полагаются на интуицию, а не на доку. Это и есть деградация в области профессионального использования ПО.

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

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

>В команде MSVS дураки сидят, ага! :)

Нет? ;)

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

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

>Ага, а links stderr не поддерживает и невозможно в запущенном экземпляре открыть URL. Хреновое межпроцессное взаимодействие.

А чего сразу на links кивать? Нормальных браузеров сейчас нет, так что говорить, что "браузер А не лучше В" не означает оправдать В.

>Ага, в заголовках окон только билиберда. Локаль юникодная.

Это проблема со шрифтами, тикль ни при чём. Точнее, может и при чём, так как не очень умеет эти шрифты находить. Проблема ведь в Tk? Tcl работает нормально. Но юникод уж точно работает.

>Слишком медленно и слишком мало виджетов. Для простого интерфейса годятся, до Qt сильно не дотягивают. :(

Не медленнее КДЕ'шных прог, а виджетов достаточно для стандартных применений. В Tk реализована база, а вам дан полёт для фантазии. Всё есть, только не из коробки.

>Это слабая эффективность. :)

Эффективность чего? Кстати, для примера: описание Tcl по знаменитому "Практическому программированию на Tcl и Tk" занимает ок. 400 страниц, раза в три меньше, чем самая известная книга по Perl. Но вы же не будете говорить, что Perl громоздкий? И потом, выбирайте то, что нужно, а не всё - эффективность повысится. И опять же, альтернативы в своей области у тикля нет.

>Ну и где его область применения? :)

Одна из областей - склеивание приложений.

>Вот я и спрашиваю: если он стандарт де-факто, то почему нигде не используется? :)

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

>Вы пытаетесь перетащить всех в консоль и Tcl/Tk,

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

>Компьютеры сейчас дёшевы, современный софт - удобнее. Так зачем возвращаться в каменный век?

Вопрос в другом: зачем менять железо каждые 3 года (то есть физического устаревания пока нет), если круг задач не изменился, а сидеть на старом софте нельзя из-за прекращения его поддержки? В компьютерре была статья - Кризис IT. Почитайте, не пожалейте время, там есть база по этому делу. http://www.computerra.ru/offline/2004/540/33390/

>Не умеете писать запросы в Google, чтобы выдало то, что нужно? :) мне обычно дальше 5 листа не нужно.

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

>Под тысячу? Похоже, вам простое нечем заниматься :)

Наоборот, но убогость средств поиска мешает этому ;)

>Читайте медленно?

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

>Про RSS слышали? :)

Это не то.

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

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

> Что самое интересное - большинство задач - это текст и его обработка. Игры и графика - исключение. Что остаётся? Сеть, текст, наука, почта, средства общения...- всё текст. Зачем что-то ещё?

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

> vi, насколько я знаю - стандарт, так что не совсем в тему. К тому же, к примеру, bash или его более компактные собратья способны на "минимальную работу", тем не менее awk тоже стандарт. Нафиг?

Ваша проблема в том, что вы чересчур идеализируете ситуации. А вот жизнь такая вредная, что взяли и не поставили vim. И что делать? Кстати, bash выступает только как оболочка для запуска и в данной ситуации не в тему. :)

> Замена плохо реализована в vim'е? А курсоры относятся к логике?

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

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

Положим, я открою вам электронную таблицу с корректировкой бизнес-плана. Разберётесь, раз задача тривиальна? Или литература потребуется? :)

Документации на все случаи не напасёшься.

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

Значит, так привыкли. Я вот тоже на автодополнение чисел и дат не сильно рассчитываю. Вот чистый текст - да, а насчёт чисел как экономист я осторожен.

> Нет? ;)

Как раз нет. Иначе кто бы пользовался их поделкой? Я, кстати, считаю, что MSVS - лучшее, что создала MS. Даже лучше MS Office и тем более MS Windows. :)

> С правильным стилем всё о-кей, если вложенность невелика. Если велика, то и фолдинг мало поможет, всё равно напрягаться надо.

Даже не знаю, чтобы я делал при отсутствии сворачивания всех блоков при просмотре исходников GTKSheet. :)

> Это проблема со шрифтами, тикль ни при чём. Точнее, может и при чём, так как не очень умеет эти шрифты находить.

Как раз шрифты (хоть и хреново) в самих диалогах рендерит русские. А вот в заголовки окна какую-то херню передаёт. KWin, естественно, показывает криво.

> Не медленнее КДЕ'шных прог...

По поводу сравнения с KDE - весьма спорно.

> Одна из областей - склеивание приложений.

Любой скриптовый язык склеивает приложения. Оставим в стороне RPC, рассмотрим широкораспространённые примеры: yum, anakonda (Python), urpmi, drakconf (Perl), автосборка/конфигурирование (Bash). И так везде: Bash, Perl, Python. Tcl/Tk ни разу не видел для склеивания приложений.

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

Ну вы вспомните ещё Prolog - раньше много на нём писали и сейчас проще дописывать, чем переписать заново. Однако это не говорит о том, что Prolog востребован. Равно как и Tcl/Tk. :)

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

Как концлагерь я рассматриваю только стремление использовать утилиты, закреплённые в POSIX, как единственно верный способ решения _прикладных_ задач и подвергание KDE/Gnome остракизму за якобы "несоблюдение стандартов". Можно долго спорить, но от этого KDE/Gnome не перестанут быть стандартами де-факто для интерфейсов.

> Вопрос в другом: зачем менять железо каждые 3 года (то есть физического устаревания пока нет), если круг задач не изменился, а сидеть на старом софте нельзя из-за прекращения его поддержки?

Ваша ошибка в том, что вы считаете, что круг задач не меняется. Посмотрите вокруг: растущая популярность мобильных устройств, цифровых фотоаппаратов, видео на подъёме, mp3-плейеры. И людям нужен софт для решения задач связи с мобильным, обработки/каталогизации звука/фото/видео. Сейчас становится доступен широким массам VoIP (Skype), картография (Google Maps), Web2. Сложно сказать, что будет дальше, но спрос на новые функции для новых задач будет всегда.

> Порообуйте сформулировать очень широкий или узкоспецифический запрос

А зачем мне писать запросы неэффективно? Я ж не первый год в Интернете, знаю, как надо запросы писать. :)

> Наоборот, но убогость средств поиска мешает этому ;)

Похоже, у вас просто мало опыта в поиске. Посмотрите документацию, пробуйте. Опыт со временем придёт. :)

> Это не то.

Вы вручную определяете последнюю новость? Речь-то идёт про новостийные сайты.

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

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

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

Я к тому, что варианты баша и awk близки по функционалу - нафиг сразу два скриптовых языка? А ведь оба - стандарт по LBS.

>Во-первых, обсуждали, что засунуто из обработки текста в KatePart. vim тут не при чём

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

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

Так и говорите - средства навигации, ваши термины трудно идентифицировать ;) Опять же, есть проблемы в виме?

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

>Положим, я открою вам электронную таблицу с корректировкой бизнес-плана. Разберётесь, раз задача тривиальна? Или литература потребуется? :)

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

>Как раз нет. Иначе кто бы пользовался их поделкой?

Windows - поделка, но ей всё пользуются. Плохая логика. ;)

>А вот в заголовки окна какую-то херню передаёт. KWin, естественно, показывает криво.

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

>По поводу сравнения с KDE - весьма спорно.

Сравните Konqueror и Browsex. Конечно, у завоевателя функций больше, но никто и не заставляет их все сразу показывать ;)

>Оставим в стороне RPC, рассмотрим широкораспространённые примеры: yum, anakonda (Python), urpmi, drakconf (Perl), автосборка/конфигурирование (Bash).

Это не склейка приложений, это - написание морды над бакэндом.

>Ну вы вспомните ещё Prolog

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

>Как концлагерь я рассматриваю только стремление использовать утилиты, закреплённые в POSIX, как единственно верный способ решения _прикладных_ задач и подвергание KDE/Gnome остракизму за якобы "несоблюдение стандартов".

Да неужели? Напомнить ваши слова про концлагерь, если вдруг останется одна Qt? Мне глубоко пофигу, на каком стандарте будет всё строится - главное, чтобы это был единый стандарт. Строить приложения с одними стандартами (КДЕ, гном) для системы на других (принципы юних в линухе) - это как минимум странно. Нет единства, целостности.

>Ваша ошибка в том, что вы считаете, что круг задач не меняется. Посмотрите вокруг: растущая популярность мобильных устройств, цифровых фотоаппаратов, видео на подъёме, mp3-плейеры. И людям нужен софт для решения задач связи с мобильным, обработки/каталогизации звука/фото/видео. Сейчас становится доступен широким массам VoIP (Skype), картография (Google Maps), Web2. Сложно сказать, что будет дальше, но спрос на новые функции для новых задач будет всегда.

Вы статью читали? Там очень хорошо показана идея "совершенствования" ПО на примере Word. Возражения по этому поводу есть? Абсолютно точно также и для других задач. Проблема не в том, что кто-то хочет супер-пупер, а его нет, а в том, что тот, кто не хочет, тот всё равно получит супер-пупер. И деньги с негj сдерут за то, что есть, а не за то, что надо.

И, как пример, уже приводившаяся ссылка в толксах на 13 МБ картинку, которая открылась с трудом лишь на проприертарном вьюере. Что говорит лишь о том, что качество софта далеко не идеальное (и падает со временем), и ресурсы компа растрачиваются впустую. И если для гнушного софта это ещё и понятно, то вот для платного - нет, пример - растолстевший ворд. То есть за лень разработчиков платит пользователь.

>А зачем мне писать запросы неэффективно? Я ж не первый год в Интернете, знаю, как надо запросы писать. :)

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

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

>Вы вручную определяете последнюю новость?

У меня не только новостные сайты открыты.

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

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

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

А зачем мне их связывать конвейерами? Что мне это даст?

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

Видно, у вас узкий спектр задач и однородные документы. Увы, современная офисная работа - это совсем не то, что вы себе представляете.

> Я к тому, что варианты баша и awk близки по функционалу - нафиг сразу два скриптовых языка?

Потому как у них разные предметные области.

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

Попробуйте сделать в vim такойже показ фолдинга/подсветки как в Kate - поймёте. Кратко: слишком много переписывать.

> Так и говорите - средства навигации, ваши термины трудно идентифицировать ;) Опять же, есть проблемы в виме?

Мда, это не совсем навигация. А в данном контексте - совсем не навигация. Учите адресацию sed. И vim тут снова не при чём. :)

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

И где велосипеды плодятся? Назовите временной интервал и количество. Мне vim не угодил визуальными возможностями и навигацией/режимами правки.

> И опять же, какое это имеет отношение к эффективности использования приложения?

Это было ответом для отражения необходимости литературы для просмотра данных.

> Windows - поделка, но ей всё пользуются. Плохая логика. ;)

У вас есть доказательства или опять мальчишеский задор и лозунги, а за ними - ничего? :)

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

Возможно, стОит почитать про стандарты FDO и не плодить велосипедов?

> Сравните Konqueror и Browsex. Конечно, у завоевателя функций больше, но никто и не заставляет их все сразу показывать ;)

А где Konqueror показывает больше? Только в настройках. :)

> Это не склейка приложений, это - написание морды над бакэндом.

Вы вообще в курсе, что такое anakonda или Drakconf? :)

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

В том то и дело, что вы не понимаете, что задачи усложняются. :)

> Да неужели? Напомнить ваши слова про концлагерь, если вдруг останется одна Qt?

Да, напомните. И можете обескураженно наблюдать уже сейчас, что я за конкуренцию и буду очень опечален, если Gnome умрёт.

> Мне глубоко пофигу, на каком стандарте будет всё строится - главное, чтобы это был единый стандарт.

Единые стандарты уже есть. Только вы, в силу отсутствия опыта и горячности, о них не слышали.

> Строить приложения с одними стандартами (КДЕ, гном) для системы на других (принципы юних в линухе) - это как минимум странно.

Вот я и хочу услышать, где KDE (или Gnome) нарушают принципы POSIX? :)

> Вы статью читали? Там очень хорошо показана идея "совершенствования" ПО на примере Word. Возражения по этому поводу есть? Абсолютно точно также и для других задач.

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

> То есть за лень разработчиков платит пользователь.

Да, и делает это с радостью. Потому как привык платить за комфорт и экономию времени. Кстати, и под Linux - также. Мне проще купить Mandriva 2006, чем тянуть и колупаться с Debian или Gentoo. :)

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

Первая заповедь эффективного поиска: "Максимально уточните запрос". Что я и делаю.

> У меня не только новостные сайты открыты.

Я имел ввиду новостийные сайты. Их то зачем держать открытыми? :)

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

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

>А зачем мне их связывать конвейерами? Что мне это даст?

Стандарт. Конвейеры - стандарт в Unix. Поэтому есть два пути: раз и навсегда избавиться от конвейеров или раз и навсегда принять их за единый стандат. Иначе будут велосипеды.

>вы, современная офисная работа - это совсем не то, что вы себе представляете.

http://www.linux.org.ru/jump-message.jsp?msgid=1367987#1369180 от progserega (*) (26.04.2006 1:11:59)

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

>Потому как у них разные предметные области.

Изначальные или "присвоенные", то есть данные разработчиком, а не исходящие от класса программы?

>Кратко: слишком много переписывать.

То есть вы за велосипеды? Я не пойму вашу позицию насчет того, что нужно делать с программой, не удовлетворяющей по функциональности: переписывать или плюнуть на неё и писать новую?

>Мда, это не совсем навигация. А в данном контексте - совсем не навигация. Учите адресацию sed. И vim тут снова не при чём. :)

А при чём тут sed? "выбор строки и прочие операции позиционирования курсора" - это вроде как навигация и всегда ею была. То есть вам нужно установить курсов в определённое место. Так в чём проблема?

>И где велосипеды плодятся? Назовите временной интервал и количество. Мне vim не угодил визуальными возможностями и навигацией/режимами правки.

http://packages.debian.org/unstable/editors/

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

>Это было ответом для отражения необходимости литературы для просмотра данных.

Литература необходима для професссиональной работы с программой. Это был ответ на ваш "интуитивный интерфейс". Давайте не будем путать методы работы с программой и решаемые программой задачи.

>У вас есть доказательства или опять мальчишеский задор и лозунги, а за ними - ничего? :)

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

>Возможно, стОит почитать про стандарты FDO и не плодить велосипедов?

Возможно, стоит вспомнить, когда создавался FDO и когда - Tk? А также тот факт, что Tk обладает кроссплатформенностью.

>А где Konqueror показывает больше? Только в настройках. :)

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

>Вы вообще в курсе, что такое anakonda или Drakconf? :)

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

>В том то и дело, что вы не понимаете, что задачи усложняются. :)

Давайте не примере работы с текстом (на десктопах): что усложнилось по сравнению с, к примеру, 1997 годом? Корпоративные задачи не предлагать.

>Да, напомните. И можете обескураженно наблюдать уже сейчас, что я за конкуренцию и буду очень опечален, если Gnome умрёт.

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

>Единые стандарты уже есть. Только вы, в силу отсутствия опыта и горячности, о них не слышали.

Стандарты может и есть - реализации их нет.

>Вот я и хочу услышать, где KDE (или Gnome) нарушают принципы POSIX? :)

Опять про Posix ;( Ну сколько можно...

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

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

Хорошо, на примере ворда представтье своё мнение, только не общее, а конкретное - какие конкретно наиважнейшие части современных вусивугов требуют вместо трёшки четвёртый пенёк с полугигом оперативы на борту?

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

>Да, и делает это с радостью. Потому как привык платить за комфорт и экономию времени.

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

Вспоминается анекдот:

Лесоруб рубил деревья тупым топором. К нему подошли и спросили, почему он его не заточик. "У меня на это нет времени" - ответил тот.

>Мне проще купить Mandriva 2006, чем тянуть и колупаться с Debian или Gentoo. :)

От пользователя такое услышать нормально. Но от разработчика...Какие говорите вы языки знаете? ;)

>Первая заповедь эффективного поиска: "Максимально уточните запрос". Что я и делаю.

А если нужен именно общий запрос, как его уточнять будете? Чтобы правильно задать вопрос, нужно знать половину ответа. Или вопрос обобщить. Что опять может привести к необходимости что-либо знать. Замкнутый круг. То есть пользователь всегда начинает с общего, и постепенно приходит к частному. Если информации по теме мало, нужно задать наиболее общий вопрос. Или вы родились со знанием всего того, что ищете?

>Я имел ввиду новостийные сайты. Их то зачем держать открытыми? :)

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

Это всё к тому, что обычно на моеё памяти все знакомства пользователя с новой технологии на лоре обычно начинаются с укоризненниго "ты не знаешь об Х??? Ламер"", но технологии и механизма поиска так никто и не указал. А вы на это способны?

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

Хорошо, на простых пользовательских десктопах делается весьма скудный набор небольших текстовых документов: письма, резюме, объявления. Ценность стиля в силу объёма никакая - WYSWYG для получения оформленного текста позволяет быстро сделать такие документы с максимумом форматирования и довольно сложной компоновки. TeX тут в пролёте.

> Стандарт. Конвейеры - стандарт в Unix. Поэтому есть два пути: раз и навсегда избавиться от конвейеров или раз и навсегда принять их за единый стандат. Иначе будут велосипеды.

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

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

...если бы это была обычная жизнь, то секретаршу бы махом уволили. :)

> Изначальные или "присвоенные", то есть данные разработчиком, а не исходящие от класса программы?

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

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

Я за альтернативы. Называть их велосипедами - плод вашего больного воображения. :) Переписывание/создание нового определяется совокупной разницей в функционале. Мне лично в E/AS проще было взять CODB из CLIP, чем доводить до ума ОБД в Python.

> "выбор строки и прочие операции позиционирования курсора" - это вроде как навигация и всегда ею была.

Учите матчасть и не позорьтесь. Начните с ed, продолжите с sed...

> А ведь была бы единая либа, но разные морды - какая была бы совместимость...

И не было бы и половины возможностей. Предлагаете скрестить WYSWYG-средства подготовки документов и программистский редактор? Кто тут говорил про монолит? :)

> Литература необходима для професссиональной работы с программой.

И насколько чтение литературы повышает эффективность использования Интернет-пейджера или браузера? :)

> Начиная от потрясающей экономичсти оси по части потребления ресурсов компа и кончая её настраиваемостью и функциональностью.

Linux c XWindow тоже далеко не экономичен. Настраивать можно как угодно

> А также такими вещами как помойка в system32, худшая ФС, отсутствие системных средств для работы с ПО, не поддерживающего настройку через реестр.

А что, в /usr/lib уже не помойка? FAT32/NTFS перестала выполнять свои обязанности? Или для ext3 появился shadow copy? Системные средства от сторонних разработчиков стали недоступны? regedit не запускается (кстати, это иногда бывает от вирусов)? В общем - мальчишеский бред, придумайте что получше. Чтобы что-то обсирать, надо хотя бы иметь об этом представление. :)

> Возможно, стоит вспомнить, когда создавался FDO и когда - Tk? А также тот факт, что Tk обладает кроссплатформенностью.

Как связан тулкито-независимый стандарт для DE и древний тулкит? Разве что Tk не соблюдает современные стандарты? Так это неудивительно и большой минус Tk.

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

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

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

Ну тогда приведите пример "склейки приложений".

> Давайте не примере работы с текстом (на десктопах): что усложнилось по сравнению с, к примеру, 1997 годом?

Рисование таблиц, веб-сервисы, более удобный внешний вид (те же боковые панели), упрощённый просмотр. :)

> Гном и Кде обладают разным софтом, нередко с непересекающейся функциональностью.

Пример непересекающейся функциональности на уровне прикладных приложений?

> Ничего подобного по функциональности (и стабильности ;), это про Krita) в конкуренте нет.

Почитайте мысли Александра Прокудина, которого сложно обвинить в пристрастии к KDE, по поводу Krita.

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

Некоторые библиотеки совпадают, а совмещать GTK+ и Qt/KDE нет смысла и это неоднократно обсуждалось.

> Причём если гномовская прога может потребовать только часть гнома, то часть КДЕ уже не ухватишь, ибо монолит.

Снова ткнуть носом в /usr/lib/kde3 и опять поймать на лжи? :)

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

Слава Богу, подобные мысли приходят в голову только ничего не сделавшим неофитам. А то просто страшно становится. :)

> Стандарты может и есть - реализации их нет.

Да неужели? Принципы FDO давно реализованы во всех популярных DE. Для вас это открытие? :)

> Опять про Posix ;( Ну сколько можно...

Потому как это единственный принятый стандарт для Unix, касающийся консольных утилит.

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

Я уже писал про использование Unix-сокетов в KDE, которые описаны в POSIX. Предпочли не заметить? :)

> Хорошо, на примере ворда представтье своё мнение, только не общее, а конкретное - какие конкретно наиважнейшие части современных вусивугов требуют вместо трёшки четвёртый пенёк с полугигом оперативы на борту?

Мультимедия и качественная печать. Устроит?

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

Нет, именно пользователя. :)

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

Пример некорректный. Ибо софт уровня KDE позволяет мне заниматься и локализацией и разработкой. :)

> От пользователя такое услышать нормально. Но от разработчика...Какие говорите вы языки знаете? ;)

Clipper, Bash, C, C++, Perl, Python, Fortran, Pascal, немного Java и Postscript. И что? Тратить время на заточку? Ну-ну. Таких умников и без меня много. Да вот толку для сообщества от них никакого. :)

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

Это говорит о слабой эрудиции и низкой культуре. :)

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

Ему нужен usecase: gg:RSS Konqueror. Соответственно, он почитает usecase'ы и решит сам, нужно ли это ему.

> Это всё к тому, что обычно на моеё памяти все знакомства пользователя с новой технологии на лоре обычно начинаются с укоризненниго "ты не знаешь об Х??? Ламер"", но технологии и механизма поиска так никто и не указал. А вы на это способны?

Для поиска информации о технологии лучшая отправная точка - Wikipedia.

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

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

>Причины я уже указывал.

Назвали, но не пояснили. Точнее, так и не смогли привести корректные примеры, когда пайпы не рулят _в составе приложения_, а не как элемент связи программ в консоли.

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

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

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

Целевое назначение обоих программ - программирование. Только у баша область несколько больше - ещё и интерфейс пользователя. Так нужен ли awk? Зачем, если всё может делать bash?

>Я за альтернативы. Мне лично в E/AS проще было взять CODB из CLIP, чем доводить до ума ОБД в Python.

Альтернативы и есть велосипеды. Это синонимы. Для простоты разработчика достаточно сваять новый интерфейс, а не плодить новые программы. Пример - компилируемые ЯП. Их много, но все они на выходе дают асм. То есть разнообразие КЯП - всего лишь богатство интерфейсов для построения асма.

>Учите матчасть и не позорьтесь. Начните с ed, продолжите с sed...

Для того, чтобы что-то понять про позиционирование курсора, нужно ещё что-то учить? Вы когда с Марса прилетели? ;) А ещё кто-то про ИПИ говорит.

>Предлагаете скрестить WYSWYG-средства подготовки документов и программистский редактор? Кто тут говорил про монолит? :)

Нет. Предлагаю сделать так, как сделано в Kate - одна либа, разные морды: quanta, Kedit, Kwrite... (а зиждилась бы эта либа на виме - цены б ей не было) Функции редактора отдельно, функции обработки текста отдельно. Ведь писать свой редактор для каждого вусивуга - верх идиотизма.

>И насколько чтение литературы повышает эффективность использования Интернет-пейджера или браузера? :)

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

>Настраивать можно как угодно

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

>А что, в /usr/lib уже не помойка?

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

>FAT32/NTFS перестала выполнять свои обязанности?

Я говорю про организацию ФС. Впрочем, какие из функций ext3 доступны на Fat32? Ссылки есть? Журналирование? Монтирование с разными опциями?

>Системные средства от сторонних разработчиков стали недоступны?

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

>regedit не запускается (кстати, это иногда бывает от вирусов)?

Странно, что вы не сторонник гнома.

>Как связан тулкито-независимый стандарт для DE и древний тулкит?

Этот стандарт для иксов. Tk - кроссптлатформенен. Вот и вся связь.

>Зачем мне быстрая скорость на моих неслабых компьютерах/нормальных каналах при отвратительной эргономике и возможностях, сберегающих моё свободное время.

Не уходите от вопроса, который вы сами и спровоцировали (насчёт скорости KDE-based и Tk-based программ): сравните скорость Browsex и Konqueror.

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

>Ну тогда приведите пример "склейки приложений".

Конвейер. Удивлены?

>Рисование таблиц, веб-сервисы, более удобный внешний вид (те же боковые панели), упрощённый просмотр. :)

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

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

>Пример непересекающейся функциональности на уровне прикладных приложений?

Ghemical и stardict для гнома. Konqueror и центр управления (нормальный,а не обрезанный, как у гнома) для KDE.

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

Мне достаточно посмотреть на стабильность КДЕшных программ, яркий пример которых- завоеватель. А криты в Debian Stable вообще нет.

>Некоторые библиотеки совпадают, а совмещать GTK+ и Qt/KDE нет смысла и это неоднократно обсуждалось.

Некоторые - это слишком мало.

>Снова ткнуть носом в /usr/lib/kde3 и опять поймать на лжи? :)

Снова рассказать, что поставить отдельную часть kdelibs и kdebase невозможно и опять поймать вас на неумении читать?

>Слава Богу, подобные мысли приходят в голову только ничего не сделавшим неофитам. А то просто страшно становится. :)

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

>Да неужели? Принципы FDO давно реализованы во всех популярных DE

FDO не только DE стандартизует. И все ли стандарты реализованы?

>Я уже писал про использование Unix-сокетов в KDE, которые описаны в POSIX

Не сокетами едины.

>Нет, именно пользователя. :)

То есть лень разработчика приводит к улучшению жизни пользователя??? Жжоте! Впрочем, как всегда.

>Мультимедия и качественная печать. Устроит?

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

>Ибо софт уровня KDE позволяет мне заниматься и локализацией и разработкой. :)

Ключевое слово - мне. Вы думаете, как и большинство других, не глобально. Так что ИМХО хоть добавляйте, чес слово...

>Clipper, Bash, C, C++, Perl, Python, Fortran, Pascal, немного Java и Postscript.

У, как много. И какой из них основной?

>Тратить время на заточку? Ну-ну.

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

>Это говорит о слабой эрудиции и низкой культуре. :)

Надеюсь, не мне объяснять, кто прививает культуру и даёт почву для роста эрудиции?

>Для поиска информации о технологии лучшая отправная точка - Wikipedia.

То есть дать очёредность действий для пользователя (своего рода хоу-ту) слабо, как и другим лоровцам - "разработчикам"?

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

Можно, если побороть лень и делать всё на стилях. Но теряется время. А это сейчас более дорогой товар и применение стилей для подобного класса документов не так важно.

> Точнее, так и не смогли привести корректные примеры, когда пайпы не рулят _в составе приложения_

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

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

Отнюдь! Работник должен делать свою работу быстро и он должен быть взаимозаменяем. Унификация преобладает над глубокими знаниями в компьютерах в офисной сфере.

> Целевое назначение обоих программ - программирование.

Ошибаетесь! Назначение Bash - автоматизация запуска команд, awk - программируемый парсинг текста.

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

Для разработчика удобнее использовать минимум API и его (API) стандартизованность.

> Для того, чтобы что-то понять про позиционирование курсора, нужно ещё что-то учить?

Курсор бывает визуальный и логический. Похоже, вы их не различаете, а зря...

> Предлагаю сделать так, как сделано в Kate - одна либа, разные морды: quanta, Kedit, Kwrite... (а зиждилась бы эта либа на виме - цены б ей не было)

Quanta, Kate, KEdit, KWrite могут использовать вместо KatePart vim. Я уже об этом писал.

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

А зачем ковырять? Я и под Linux стараюсь не ковыряться, чтобы не терять время.

> Впрочем, возможно вы про мандриву говорите?

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

> Я говорю про организацию ФС.

Про shadow copy вы намеренно опустили? :)

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

Конечно! Я не ламер - ставить всякую фигню что на Windows, что на Linux. :)

> Странно, что вы не сторонник гнома.

Просто я прагматичен и использую сильные стороны технологий и приложений. Например, хоть я и люблю Qt, для E/AS выбрал GTK+. Зашоренность и фанатизм - враг эффективности. :)

> Не уходите от вопроса, который вы сами и спровоцировали (насчёт скорости KDE-based и Tk-based программ): сравните скорость Browsex и Konqueror.

Увы, yum сообщает, что "No Match for argument: browsex". А собирать неохота.

> Новые компы нужны для новых программ.

Нет, они нужны для комфорта: usb2, Wi-Fi, бОльшие диски для мультимедиа, пишущие DVD, больше памяти для обработки больших медийных файлов. :)

> Конвейер. Удивлены?

И насколько часто в быту это необходимо? :)

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

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

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

Можете, если перепишите. Только вот помощников в этом нелёгком труде у вас немного будет. :)

> Ghemical и stardict для гнома. Konqueror и центр управления (нормальный,а не обрезанный, как у гнома) для KDE.

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

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

У меня они стабильны. Может, сборки FC и Mandriva делаются по уму, а не как в Debian? :)

> Некоторые - это слишком мало.

Для работы - достаточно. Проблема всеобщей стандартизации на уровне совместных библиотек в предлагаемом вами объёме никого, кроме вас, не интересует.

> Снова рассказать, что поставить отдельную часть kdelibs и kdebase невозможно и опять поймать вас на неумении читать?

Расскажите. А то у меня на Mandriva пакеты kdelibs/kdebase раздроблены и сказки я слышу только от вас. :)

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

Пусть велосипедов, если они позволяют мне быстро и эффективно делать мою работу. Фанатизм - не для меня. :)

> FDO не только DE стандартизует. И все ли стандарты реализованы?

В общем случае - все. Хотя стандарт постоянно дописывается. Неудивительно, что что-то не успели реализовать.

> Не сокетами едины.

То есть, сокеты используются, стандарт соблюдается, а ваши крики про "нестандартность" так и остались голыми лозунгами. :)

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

Как ни удивительно, но это правда. Пользователь получает готовый продукт, а не конструктор "сделай сам". Все довольны, кроме некоторых студентов. :)

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

На 1200dpi с цветоделением? И для кучи шрифтов сколько будет генерится PS? :)

> А мультимедиа в доках уже жизненно необходима? Просто для поиграться?

Необходима. Реалии бизнеса и хорошего тона. Не бойтесь, вас на серьёзные презентации и не пустят. :)

> Ключевое слово - мне. Вы думаете, как и большинство других, не глобально. Так что ИМХО хоть добавляйте, чес слово...

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

> У, как много. И какой из них основной?

Clipper, Bash.

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

Опять сказки на базе отсутствующего опыта? :)

> Надеюсь, не мне объяснять, кто прививает культуру и даёт почву для роста эрудиции?

Родители и учителя. Может, мне повезло на родителей и учителей. Ещё опыт - сын ошибок трудных. :)

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

"Слабо" будете своим приятелям прыщавым в подъезде говорить. :) А что, посыл на Wikipedia уже не моден? Вы черпаете знания из журнала "Xakep"? :)

>Можно, но теряется время.

Жжоте!!! Со стилями вы, видимо, не работали, или работали, но не так. Хотя интересно девки пляшут: по-вашему, стили в Qt рулят, а в средствах подготовки документации - нет.

>Пайпы в составе приложений используются крайне редко.

Как всегда, причины с примерами вы привести не можете, разработчик вы наш? ;)

>Работник должен делать свою работу быстро и он должен быть взаимозаменяем.

Что такое "квалифицированный специалист" вам, видимо, неизвестно.

>Назначение Bash - автоматизация запуска команд, awk - программируемый парсинг текста.

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

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

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

>Курсор бывает визуальный и логический. Похоже, вы их не различаете, а зря...

Уточнять надо, про какой идёт речь. И с какими курсорами проблемы в виме?

>Quanta, Kate, KEdit, KWrite могут использовать вместо KatePart vim. Я уже об этом писал.

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

>А зачем ковырять?

Вы что-то говорили про настраиваемость, так? Вот затем и ковырять. По-вашему, regedit или gnome-config логичнее K Control Panel и прямого редактирования конфигов?

>RPM позволяет то же самое.

А про помойку в rpm-based дистрах что-нить скажете? В Debian-based её просто нет.

>Про shadow copy вы намеренно опустили? :)

Я не знаю, что это. Значит, мне это не нужно. А если вы сами не сказали, что это, то это не нужно и вам.

>Я не ламер - ставить всякую фигню что на Windows, что на Linux. :)

"Всякая фигня" в лице Norton Utilites иногда коцала всю ФС или часть файлов.

>Просто я прагматичен и использую сильные стороны технологий и приложений.

Реестр - сильная тенология??? Жжоте второй раз.

>Увы, yum сообщает, что "No Match for argument: browsex". А собирать неохота.

А бинарник с сайта взять не судьба? www.browsex.com.

>Нет, они нужны для комфорта: usb2, Wi-Fi, бОльшие диски для мультимедиа, пишущие DVD, больше памяти для обработки больших медийных файлов. :)

Жизнь многих пользователей сложка...но интересна... ;)