LINUX.ORG.RU
Новости — Linux General  

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


0

0

Ларру Августин (VA Software), Эрик Реймонд (основатель Open Source Institute), Джон Мэддог Хол (Linux International), Крис Дибона (Google), и Дирк Хондел (Intel) в дружеской беседе обсудили ряд вопросов, обсуждение которых неизменно приводило к потокам бурного флейма на ЛОР, а именно ...

>>> что именно (на английском)

★★★

Проверено: Pi ()

 ← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 →
Ответ на: комментарий от anonymous

> А можно пример чего-л. более популярного и ... совершенного? ;)

1С:Предприятие.

> То есть там изобрели пайпы?

Не совсем. Скорее, графический аналог screen

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

Это один из принципов (см. Wikipedia). Но ПО усложняется и возникает потребность передавать сложные структуры. Подробности: http://developer.kde.org/documentation/books/kde-2.0-development/ch13.html При этом снимается ограничение на запоминание форматов обрабатываемых данных, что присуще пайпам.

> aptitude - стандартный инструмент Debian. Разве в Ubuntu не так?

Не так. Удивлены?

> Только не говорите, что вы понимаете всё, но объяснять не будете ибо лень ;)

Я уже писал про эффективность. См. Wikipedia - там всё хорошо объяснено.

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

Если бы эффективность была выше, их бы и использовали повсеместно. Увы, оставили только в узких нишах. Потому как невыгодно для пользователей.

> Что-нибудь в духе "первая цифра версии - ноль"? :)

Никогда не заморачивался номерами версий. Были работающие приложения для АТС.

> Я думаю, не так сложно, к примеру, вместо <html> ...</html> поставить puts "<html> ... </html>", а не каждую строчку выводить. Кроме того, легко сделать шаблон.

Для программы типа Hello, world несложно. Для более крупных проектов не годится. :)

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

Можно подумать, шаблоны/регэкспы невозможно совместить с GUI? При этом обеспечивая автообновление. Вы давно Konqueror видели?

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

Да. И для нынешних задач автоматизируемость вырабатывается.

> Но, тем не менее, вы осуждаете GTK+. Мне лишь хотелось убедиться в справедливости такого решания.

Потому и осуждаю, что реально с ним работаю в E/AS.

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

Я начинал с Corel PhotoPaint, Photoshop только на картинках и видел. И, имея перед глазами примеры GIMP и Krita, делаю выводы при обработке изображений. Даже при глюкавости Krita само юзабилити явно не на стороне GIMP.

Skull ★★★★★
()
Ответ на: комментарий от dn2010

'Проверка боем. Подлинная история боевой ударной группы': http://airforce.ru/articles/ka-50/index.htm - боевое применение Ка-50 в Чечне (правда их всего пара штук там была)

anonymous
()
Ответ на: комментарий от dn2010

> Слабое зенитное вооружение

Фигасе слабое! Это те, описанные выеше возможности слабые??? Куда сильней-то для такой маленькой посудины? Как у крейсера что ли должно быть??? А может у вражеских корветов оно сильней и даже намного сильней??? Например у какого?

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

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

..."быстро расстреляет зенитные ракеты" ...это ж какую атаку вражеской авиации должен быть способен отбить один маленький корветик? Примерно как при Мидуэй что ли их будет? ;) Штук нескольно сбить вполне способен, на чудо никто и не расчитывает. Серьёзные атаки авивации вероятно должны отражать более серьёзные корабли.

> Скорость полного хода у него маловата на 5 узлов по сравнению с кораблями, строящимися по НАТОвским стандартам.

Удирать не наш метод - будем сражаться и петь "врагу не сдаётся наш гордый..."! )) да и от ракеты не особо удирёшь ;) Кстати, ты знаешь много вражеских корветов, где сзади стоит пушка? ...и вообще более мощно вооружённых, с лучшими ПВО и лучшей продиволодочной защитой? Может огласишь длинный список? Ну хоть пару? Если нужна скорость, то другой корвет, более старый, может сгодиться - 'Сивуч' выдаёт аж 53 узла - враги нервно курят в сторонке ;) У пиндосовских корветов только в проекте близкие скорости. Да и у 'Стерегущего' всё-таки тоже не очень плохо - 28 узлов, хотя не фонтан конечно. Штатовский Bear если не ошибаюсь всего 20 выдаёт - старьё ещё то. Чего нет в нашем 'Стерегущем' (так и подмывает сказать 'стригущий' почему-то :)) так это модной стелсовости, типа как в уже стоящем на вооружении шведском Visby или проектах пиндосовских.

anonymous
()
Ответ на: комментарий от anonymous

>Фигасе слабое! Это те, описанные выеше возможности слабые??? Куда сильней-то для такой маленькой посудины? Как у крейсера что ли должно быть??? А может у вражеских корветов оно сильней и даже намного сильней??? Например у какого?

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

>..."быстро расстреляет зенитные ракеты" ...это ж какую атаку вражеской авиации должен быть способен отбить один маленький корветик? Примерно как при Мидуэй что ли их будет? ;) Штук нескольно сбить вполне способен, на чудо никто и не расчитывает. Серьёзные атаки авивации вероятно должны отражать более серьёзные корабли.

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

>Удирать не наш метод - будем сражаться и петь "врагу не сдаётся наш гордый..."! )) да и от ракеты не особо удирёшь ;) Кстати, ты знаешь много вражеских корветов, где сзади стоит пушка? ...и вообще более мощно вооружённых, с лучшими ПВО и лучшей продиволодочной защитой? Может огласишь длинный список? Ну хоть пару? Если нужна скорость, то другой корвет, более старый, может сгодиться - 'Сивуч' выдаёт аж 53 узла - враги нервно курят в сторонке ;) У пиндосовских корветов только в проекте близкие скорости. Да и у 'Стерегущего' всё-таки тоже не очень плохо - 28 узлов, хотя не фонтан конечно. Штатовский Bear если не ошибаюсь всего 20 выдаёт - старьё ещё то. Чего нет в нашем 'Стерегущем' (так и подмывает сказать 'стригущий' почему-то :)) так это модной стелсовости, типа как в уже стоящем на вооружении шведском Visby или проектах пиндосовских.

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

dn2010 ★★★★★
()
Ответ на: комментарий от Skull

> Даже при глюкавости Krita само юзабилити явно не на стороне GIMP.

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

sin_a ★★★★★
()
Ответ на: комментарий от Skull

>> А бинарные потоки противоречат принципам Unix :Всё - текст.

> Это один из принципов (см. Wikipedia). Но ПО усложняется и возникает потребность передавать сложные структуры.

Вообще, в идеале было-бы действительно иметь дело (в основном) с текстом. В широком смысле (грубо - музыка midi, векторное изображение). Но это дело нескорого будущего.

sin_a ★★★★★
()
Ответ на: комментарий от Skull

>1С:Предприятие.

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

>Скорее, графический аналог screen

Я не знаю всех возможностей screen - оконного менеджера для консоли. Гугл на "задаче-ориентированный десктоп" выдает поразительно много информации. Так что желательно поподробнее - я не телепат.

>Это один из принципов

Который нарушается в КДЕ - согласен.

>Но ПО усложняется и возникает потребность передавать сложные структуры. Подробности: http://developer.kde.org/documentation/books/kde-2.0-development/ch13.html

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

>При этом снимается ограничение на запоминание форматов обрабатываемых данных, что присуще пайпам.

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

>Я уже писал про эффективность. См. Wikipedia - там всё хорошо объяснено.

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

Далее: "Международный стандарт ISO 9241-11 определяет юзабилити как &#171;cтепень, в которой продукт может быть использован определёнными пользователями при определённом контексте использования для достижения определённых целей с должной эффективностью, продуктивностью и удовлетворённостью&#187;"

Однако "The primary notion of usability is that an object designed with the users' psychology and physiology in mind are, for example:

More efficient to use&#8212;it takes less time to accomplish a particular task Easier to learn&#8212;operation can be learned by observing the object More satisfying to use"

То есть, в основном, простота и Windows-way. О какой эффективности идет речь? Использования, обучения или эффективности труда?

>Если бы эффективность была выше, их бы и использовали повсеместно.

Тот же вопрос.

>Для более крупных проектов не годится. :)

А почему для более крупных программ не учитывается доля встраиваемого языка в общей доле html кода? Иначе такой уверенности бы не было.

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

>Можно подумать, шаблоны/регэкспы невозможно совместить с GUI?

Пайпы несовместимы с GUI. Точнее, с интерактивным выполнением. ГУЙ должен прикрывать пайпы, а не давать возможности использования их - иначе какой смысл в гуе? А в данном случае что-либо сложное с файлам уже не сделаешь, если только ручками. А если сделаешь, то смысл в гуи не видно - он может быть хотя бы аля mc.

>Да.

Сложная жизнь. ;) Я всегда думал, что используются стандартные средства + ЯП, а тут...Вот и пользуйся после этого КДЕ ;)

>Потому и осуждаю, что реально с ним работаю в E/AS.

Однако, на лавры программиста не претендуете. ЗАмкнутый круг.

>И, имея перед глазами примеры GIMP и Krita, делаю выводы при обработке изображений. Даже при глюкавости Krita само юзабилити явно не на стороне GIMP.

Используйте таб-ориентированные WM - вот вам и Krita из GIMP. А вот обратной модификации не сделаешь. Ну, и какой интерфейс более гибок? ;)

anonymous
()
Ответ на: комментарий от anonymous

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

С чего это вдруг? Или 1С стал не нужен? :)

> Так что желательно поподробнее - я не телепат.

Жаль, прикрыли старый форум kdeartists.org. Там это было. Вкратце: окна приложений группируются и привязываются к сеансам (задачам). Пока было доступно в mockup. Не знаю, что придумают дальше, время ещё есть.

> Который нарушается в КДЕ - согласен.

Неправда. Встраивание консоли в приложения KDE уже отменили?

> Так и не понятно отсутствие использования встраиваемых интерпретаторов аля tcl.

Нафига, если можно комбинировать вызовы dcop в любом скриптовом языке?

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

dcop --help

> можно пример по ограничению в консоли того, что вы сказали?

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

> То есть, в основном, простота и Windows-way. О какой эффективности идет речь? Использования, обучения или эффективности труда?

Там же написано - определяется задачей. В основном - эффективность использования/труда.

> А почему для более крупных программ не учитывается доля встраиваемого языка в общей доле html кода? Иначе такой уверенности бы не было.

Дело не в пропорциях, а в скорости разработки. Проше внедрить кусок инвариантного HTML as is, не заморачиваясь с операторами вывода.

> Пайпы несовместимы с GUI. Точнее, с интерактивным выполнением.

Использование пайпов как внутри GUI программно, так и интерактивно не противоречит GUI. В качестве примера можно привести текстовые фильтры Kate и встроенную консоль Konqueror/Kate...

> Однако, на лавры программиста не претендуете. ЗАмкнутый круг.

А что, разрабатывать приложения непрофесисональным программистам уже запрещено? :)

> Используйте таб-ориентированные WM - вот вам и Krita из GIMP. А вот обратной модификации не сделаешь. Ну, и какой интерфейс более гибок? ;)

И как вы там реализуете док-окна? Только не говорите, что они не нужны. Я вас умоляю! :)

Skull ★★★★★
()
Ответ на: комментарий от Skull

>С чего это вдруг? Или 1С стал не нужен? :)

_Пользователям_ Linux? А зачем? ;)

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

Afterstep 2 обладал возможностью группировки окон по задачам, правда, не знаю, автоматически ли группируются или вручную. ИМХО, при интенсивной работе не очень удобно, ибо наиболее интенсивно выполняемые задачи дают бо'льшее количество окон, то есть придется планировать количество окон заранее. Да и не очень понятно, какие цели это несёт - запоминать соответствие воркспейса задаче так тяжело?

>Неправда. Встраивание консоли в приложения KDE уже отменили? Нафига, если можно комбинировать вызовы dcop в любом скриптовом языке? dcop --help

Все это не является стандартным. Tcl, к примеру (уж пардон за его навязывание) разработан в 1990 году, и вместо того, чтобы его использовать и делать архитектуру типа фронтэнд+бакэнд, делают монолит + костыль DCOP. Зачем изобретать велосипед, если уже были средства до него? Ведь использование встраиваемого языка даст тот же эффект, но будет более стандартно. DCOP Используется в KDE, а не во всех приложениях. Используя бы его другие программы, проблем бы не было. Но его не используют - проектировался для KDE. Здесь та же ситуация, что и для тулкитов - необходимо ставить бибилиотеки нескольких средств, а не одного стандартного, чтобы сделать универсальный комп. И делать костыли для работы этих средств между собой.

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

man?. Кстаии, под запоминанием форматов понималось запоминание кем? Человеком?

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

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

>Проше внедрить кусок инвариантного HTML as is, не заморачиваясь с операторами вывода.

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

>Использование пайпов как внутри GUI программно, так и интерактивно не противоречит GUI. В качестве примера можно привести текстовые фильтры Kate и встроенную консоль Konqueror/Kate...

Это всё нахлобучки, когда одной архитектуре навязываются возможности другой. При frontend-backend встраиать ничего не нужно было и возможностей было бы больше.

>А что, разрабатывать приложения непрофесисональным программистам уже запрещено? :)

Я просто проверял достоверность вашего мнения о GTK.

>И как вы там реализуете док-окна? Только не говорите, что они не нужны. Я вас умоляю! :)

http://www.google.ru/search?hl=ru&ie=windows-1251&q=%E4%EE%EA-%EE%EA%...

anonymous
()

Прочитал название треда, пролистал содержимое. Великих мира сего ни одного не нашел...

anonymous
()
Ответ на: комментарий от anonymous

> _Пользователям_ Linux? А зачем? ;)

Странный вопрос - чтобы вести бухгалтерский и оперативный учёт. :)

> Все это не является стандартным. Tcl, к примеру (уж пардон за его навязывание) разработан в 1990 году

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

> вместо того, чтобы его использовать и делать архитектуру типа фронтэнд+бакэнд, делают монолит + костыль DCOP.

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

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

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

> Используя бы его другие программы, проблем бы не было.

Во-первых, про консольный dcop я уже писал. Во-вторых, KDE переходит на D-BUS. Это тоже писал. Вы вообще всё читаете?

> man?. Кстаии, под запоминанием форматов понималось запоминание кем? Человеком?

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

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

Предлагаете звукорежиссёрам, художникам, аниматорам и финансовым аналитикам делать свою работу в консоли? :)

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

Потом помнить все функции? Оригинально!

Про док-окна - поищите "dock-window"

Skull ★★★★★
()
Ответ на: комментарий от Skull

>Странный вопрос - чтобы вести бухгалтерский и оперативный учёт. :)

Ага, а предприятие - это муж, жена и дочь-тинейджер? ;)

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

Ну-ну. На нём написан конфигуратор ядра 2.4.xx - часть Linux стандартней некуда. А синтаксис - прямое наследие функциональных языков, смысл открывается только избранным. На первый взгляд неудобно, но только на первый взгляд.

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

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

>А также динамическое управление приложениями. :)

Ссылку в гугле. Какие-то нестандартные названия, раз гугл обламывается.

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

Почему? Привязка ГУИ к встраиваемому языку даст возможность управлять приложением, а про плохую управляемость вообще непонятно.

>Во-первых, про консольный dcop я уже писал. Во-вторых, KDE переходит на D-BUS. Это тоже писал.

Ага, из описания dbus: DBUS is still under heavy development. И опять, менее стандартен уже существующих средств.

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

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

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

>Предлагаете звукорежиссёрам, художникам, аниматорам и финансовым аналитикам делать свою работу в консоли? :)

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

>Потом помнить все функции? Оригинально!

Предлагаете запоминать соотвектствие кусков html структуре? не менее оригинально. Вам вообще знакомо использование библиотек и структурное программирование?

anonymous
()
Ответ на: комментарий от Skull

>Про док-окна - поищите "dock-window"

Почитал про док-окна. http://www.codeproject.com/wtl/wtldockingwindows.asp

Так и не понял их отличие от окон GIPM при хорошем WM. Фактически, док-окна - результат написания мини-WM внутри приожения. Очередной велосипед? Окнами всегда управлял WM, а не приложение.

anonymous
()
Ответ на: комментарий от anonymous

> Ага, а предприятие - это муж, жена и дочь-тинейджер? ;)

Ну и зачем сарказм? Любая фирма.

> Ну-ну. На нём написан конфигуратор ядра 2.4.xx - часть Linux стандартней некуда.

Конфигуратор оттуда же есть и на Qt. Получается, Tcl ни капли не стандартней Qt. Да и не говорите про стандарты, а то вы идёте по узкому краю, так как официальных стандартов очень мало.

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

Поэтому в обычной жизни неприменим. ЧТД. :)

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

Я так и понял, что про konsolekaledar вы не в курсе. Также как и про dcop. Скажите, какой сакральный смысл в ущерб функциональности плодить консольные утилиты? Чем dcop не угодил?

> Ссылку в гугле. Какие-то нестандартные названия, раз гугл обламывается.

Не умеете пользоваться Гуглом, смотрите в Wikipedia: http://en.wikipedia.org/wiki/DCOP

> Почему? Привязка ГУИ к встраиваемому языку даст возможность управлять приложением,

Как? Переписывать каждый раз логику? :)

> а про плохую управляемость вообще непонятно.

Имелась ввиду плохая управляемость кода для разработчиков. Прозрачное API и механизмы IPC намного упрощают разработку по сравнению со свалкой внутренних методов на C или Tcl.

> Ага, из описания dbus: DBUS is still under heavy development. И опять, менее стандартен уже существующих средств.

Ага, HAL через торсионные поля информацию пересылает. Не знаете, лучше молчите. Сами себя же позорите.

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

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

> А консоль им поможет лишь консолидировать ресурсы и инструменты.

LOL! Они, в отличие от вас, делом заняты, а не разгребанием файлопомоек в консоли.

> Предлагаете запоминать соотвектствие кусков html структуре?

Так HTML-код уже встроен в страницу. :)

> не менее оригинально. Вам вообще знакомо использование библиотек и структурное программирование?

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

P.S. Спор начинает потихоньку заходить в тупик. Вы показали свою некомпетентность по всем вопросам. Есть ли смысл продолжать?

Skull ★★★★★
()
Ответ на: комментарий от anonymous

> Фактически, док-окна - результат написания мини-WM внутри приожения. Очередной велосипед? Окнами всегда управлял WM, а не приложение.

Садитесь, два! Хоть бы попробовали док-окна в деле. Такой дремучий ламеризм сил уже терпеть больше нет.

Skull ★★★★★
()
Ответ на: комментарий от Skull

>Ну и зачем сарказм? Любая фирма.

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

>Конфигуратор оттуда же есть и на Qt. Получается, Tcl ни капли не стандартней Qt.

На Qt конфигуратор, насколько я знаю, стал доступен только для 2.6. Да, в этом случае Qt тоже стандарт, увы, ибо монстр. Но, я думаю, вы не будете спорить, что наиборльший стандарт - интерфейс Motif, который и повторяет Tk и который далёк от Qt.

Ну да ладно, скриптовые языки - это не тулкиты. Какой из встраиваемых скриптовых языков наиболее стандартен? Я знаю только Lua и Tcl.

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

"Если почти все люди ходят на двух ногах, то это стандарт, несмотря на отсутствие ГОСТов" (с) кто-то с ЛОРа.

>Поэтому в обычной жизни неприменим. ЧТД. :)

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

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

Я тоже не вижу сакрального смысла плодить консольные утилиты, в то время как все нужные уже есть в Unix и являются стандартными. В качестве примера уже был приведён Downloader for X. Kget, к моему изумлению, где-то в сети называвшийся фронтэндом к wget, оказывается тоже имеет свой движок.

>Не умеете пользоваться Гуглом, смотрите в Wikipedia: http://en.wikipedia.org/wiki/DCOP

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

>Как? Переписывать каждый раз логику? :)

Как это делает консольный dcop, также и с использованием более стандартных средств.

>со свалкой внутренних методов на C или Tcl.

Где это свалка внутренних методов? Если у вас все программы пишутся по шаблону, то как раз получится стандартный набор методов. Если же вы делаете так, как это сделдано в гноме, то и dcop не поможет.

>Ага, HAL через торсионные поля информацию пересылает.

Про эффективность HAL уже было сказано, если не ошибаюсь в этом же топике. Ну давайте, скажите, что hal - стандартное юниховое средство.

>Пользователь запускает полнофункциональные приложения для решения своих задач. Если он получает приложения из сомнительных источников, то ему никто не поможет. Кстати, набор скриптов делает ситуацию ещё хуже - код проще подменить и сложно отследить. Фактически вы предлагаете ввести костыли, способствующие распространению вирусов. Славно! :)

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

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

>OL! Они, в отличие от вас, делом заняты, а не разгребанием файлопомоек в консоли.

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

>Так HTML-код уже встроен в страницу. :)

Ага, вот так сразу? На пустой странице вдруг ни с того, ни с сего появляется встроенный html-код? Или ок сначала копипастится из другого документа?

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

Шаблоны спасут отца русского КДЕ. написать что-то вроде std_begin Transitional; std_head {Название страницы}; std_body style1 style2 style3 {html_body1 html_body2 html_body3 ... [sum std_element]} для любой страницы сложнее копипаста?

anonymous
()
Ответ на: комментарий от Skull

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

Это вам так кажется. А всё потому, что я смотрю на ситуацию в общем как пользователь, а вы лезете в дебри как разработчик. Соответственно, преодолевая локальные трудности, движетесь к глобальной катастрофе (с) кто-то. Не я один уверен во всём том чо я говорю. Не верите - устройте опрос. И не только аноимусы, но и более профессиональные разработчики чем вы, подтвердят мои слова. Если моих знаний хватает понять прелесть Unix-way, то вот понять сложность KDE как кучу костылей и подпорок я не в состоянии. А вы не в состоянии доходчиво это объяснить, полагаясь на старую лоровскую традицию отправлять в гугл и в другие, не столь отдалённые места. Вы походжи на birdie, который, не в силах прогнуть мир под себя, сам прогибается под него.

>Хоть бы попробовали док-окна в деле.

Я дождусь ссылку на приложение? Krita не предлагать, в Debian он нестабильный (неудивительно, ведь он для KDE), а менять всю систему из-за него не собираюсь.

anonymous
()
Ответ на: комментарий от Skull

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

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

vtVitus ★★★★★
()
Ответ на: комментарий от anonymous

> Ещё раз - мы о пользователях говорим. Десктопщиках.

Вот как раз отсутствие программ уровня 1С и Консультант+ сильно сдерживают использование Linux на десктопах. По крайней мере - в России.

> Какой из встраиваемых скриптовых языков наиболее стандартен? Я знаю только Lua и Tcl.

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

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

То, что они более подходящие для мат. моделирования, может совсем не означать пригодность для других задач. Это я к тому, что в своё время для E/AS рассматривался и Ocaml. Но не прошёл по ряду причин.

> Дали русское название, жду русских ссылок.

А если нет на русском?

> Как это делает консольный dcop, также и с использованием более стандартных средств.

Ну вот dcop и d-bus это делают. А как вы сделаете для Tcl?

> Если же вы делаете так, как это сделдано в гноме, то и dcop не поможет.

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

> Ну давайте, скажите, что hal - стандартное юниховое средство.

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

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

Пардон, а как он перестаёт контролировать процессы в системе? ps/ksysguard чудесным образом испаряется?

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

В чём заключается слом?

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

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

> Ага, вот так сразу? На пустой странице вдруг ни с того, ни с сего появляется встроенный html-код?

Да, набивается непосредственно, без обёрток.

> Шаблоны спасут отца русского КДЕ.

Шаблоны применимы в однотипных решениях. А это случается далеко не всегда.

Skull ★★★★★
()
Ответ на: комментарий от anonymous

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

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

> Если моих знаний хватает понять прелесть Unix-way, то вот понять сложность KDE как кучу костылей и подпорок я не в состоянии.

В своём письме о создании KDE Маттиас Этрич как раз и писал о том, что KDE позволит сделать работу под Unix удобной. Что и имеем. Я тоже понимаю простоту и красоту Unix, но эта простота при всё более усложняющимися требованиям к современному десктопу становится обузой. И я рад, что KDE сохранила идеологию Unix. Увы, вы показали, что понять как в KDE реализованы подходы Unix не в состоянии. Просто потому, что не можете абстрагироваться от реализации CLI.

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

Я и не прогибаю мир под себя. И сам не прогибаюсь. Просто задела ваша некомпетентность в обсуждении KDE.

> Я дождусь ссылку на приложение?

KDevelop, Kate, Kivio, Krita. :)

Skull ★★★★★
()
Ответ на: комментарий от vtVitus

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

Вот в том и проблема, что _излишне_ твёрдая. Оппонент не хочет и не может понять доводов. Он зациклился на реализации CLI, а мне приходится отбиваться от его безосновательных нападок на KDE.

Если бы он постарался хотя бы пощупать (я уж не говорю про "поработать") с названным инструментарием, и спору бы особого не было.

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

Skull ★★★★★
()
Ответ на: комментарий от anonymous

> Вы думаете, на ЛОР ходят Windows админы?

Их просто на свете очень мало :) Почитайте про "Zero Administration for Windows". А еще лучше почитайте http://www.bloglenta.ru/author/4675/

Pilgrim

anonymous
()
Ответ на: комментарий от Skull

>Вот как раз отсутствие программ уровня 1С и Консультант+ сильно сдерживают использование Linux на десктопах.

А я думал, что сдерживанию способствует отсутствие игр. Ан нет, 1C- вот главный сдерживающий фактор. Как представлю стандартный десктоп пользователя, снабжённого 1C, и непременно "Предприятие", так сразу дрожь в коленках : "А ведь под Linux такого нет!"

>В качестве стандартов "де-факто" Python более стандартен.

Хорошо, пусть будет питон, хотя он и более громоздок. Смысл от этого не меняется.

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

У вас в академии были "другие задачи"? А в школе? Для начала учат именно решению мат. задач.

>А если нет на русском?

Ну, тогда, во-первых, мой привет команде локализации КДЕ, член которой утвердждает необходимость знания терминов, описание котрых в стандартной помощи КДЕ отсутствует. А во-вторых, ещё раз прошу обратить внимание на просьбу давть определения на том же языке, что и описания. Если у "динамического управления приложениями" нет русского описания, откуда сам термин взялся? Из головы?

>Ну вот dcop и d-bus это делают. А как вы сделаете для Tcl?

Читайте по губам (виртуальным, видно их, нет?): Так же, как это сделано с помощью dcop, но более стандартными средствами.

>GNOME, как раз, прекрасно показывает во что превращаются C-шные программы в больших сложных проектах. Для небольших утилит C идеален, но для крупных сложных проектов - нет. И не надо мне рассказывать про ядро - там хак на хаке и хаком погоняет. :)

А GCC? А X? Да, гном жирный и тормозной, но вряд ли это только из-за C, ведь чисто GTK программы работают быстро. Во всяком случае, он стабильный.

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

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

>Пардон, а как он перестаёт контролировать процессы в системе?

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

>В чём заключается слом?

В преимущественном направлении системы на путь Windows-way.

>В консоли бы это потребовало куда как больше усилий.

Работа с файлами и пайпами требуют невероятных усилий?

>Шаблоны применимы в однотипных решениях. А это случается далеко не всегда.

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

anonymous
()
Ответ на: комментарий от Skull

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

Да, но объяснить внятно свои суждения вы не можете.

>но эта простота при всё более усложняющимися требованиям к современному десктопу становится обузой.

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

>Увы, вы показали, что понять как в KDE реализованы подходы Unix не в состоянии.

А вы показали, что вы не в состоянии этого объяснить, как и то, почему в КДЕ ломают архитектуру Unix, в том числе не используют структуру фронтэнд - (стандартный для Unix) бакэнд, а вместо этого пишут монолит с нахлобучкой из консоли.

>KDevelop, Kate, Kivio, Krita. :)

По Kate есть справочник в KDE. Про MDI там написано, про док-окна - нет. В "глоссарии" термин "док-окна" отсуствуют.

anonymous
()
Ответ на: комментарий от Skull

>Он зациклился на реализации CLI

А вот и неверно. Я говорю про архитектуру Unix. Я вовсе не против GUI, если бы он был бы в соответствии с Unix-way.

anonymous
()
Ответ на: комментарий от anonymous

> А я думал, что сдерживанию способствует отсутствие игр.

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

> У вас в академии были "другие задачи"? А в школе? Для начала учат именно решению мат. задач.

Конечно. Мат. задачи я могу и в уме вычислять.

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

При чём тут справка? Я ввожу на Google "динамическое управление приложениями KDE" и получаю то, что нужно. Не осилили? :)

> Читайте по губам (виртуальным, видно их, нет?): Так же, как это сделано с помощью dcop, но более стандартными средствами.

Ну да, весь спектр функций через сигналы? Может, примеры приведёте? :)

> Если пользователь даже не знает (и не хочет знать) ,какой формат запускает и что делает, о каком контроле идёт речь?

В KDE он это может проконтролировать в контекстном меню и воспользоваться пунктом "Открыть в...". Только непонятно, зачем нужна такая паранойя? :)

> В преимущественном направлении системы на путь Windows-way.

Тогда давайте определимся что есть "Windows way" и в чём его отличие от "Unix way".

> Работа с файлами и пайпами требуют невероятных усилий?

В сложных задачах - да.

> Если вы собираетесь вставлять одинаковые куски, то их можно вставить одной командой.

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

Skull ★★★★★
()
Ответ на: комментарий от anonymous

> Да, но объяснить внятно свои суждения вы не можете.

Почему же, считаю, что всё объяснил. Просто вы читать не хотите.

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

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

> А вы показали, что вы не в состоянии этого объяснить, как и то, почему в КДЕ ломают архитектуру Unix

Пока я услышал лишь про пресловутый "Windows way", определения которому вы не дали. Жду определения.

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

На http://en.wikipedia.org/wiki/Unix_philosophy нет ни слова про backend. Опять придумываете? К тому же вы показали, что не в состоянии осмыслить работу KPart и DCOP.

> По Kate есть справочник в KDE. Про MDI там написано, про док-окна - нет. В "глоссарии" термин "док-окна" отсуствуют.

Плохо читали! "Главное окно Kate -- это стандартное окно приложения KDE с несколькими зависимыми окнами (т.н. окнами инструментов), которые могут быть &#171;пристыкованы&#187; к главному окну (см. описание ниже)." Док-окна - это сокращение для "окон инструментов". :)

Skull ★★★★★
()
Ответ на: комментарий от Skull

>Корпоративные пользователи платят за софт/услуги много больше и стабильнее.

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

>Мат. задачи я могу и в уме вычислять.

Решить уравнеие шредингера тоже в уме можете? Или в школе вы 2+2 прогали? ;)

>Я ввожу на Google "динамическое управление приложениями KDE" и получаю то, что нужно.

http://www.google.ru/search?hl=ru&inlang=ru&ie=windows-1251&q=%C4...

Ммм... Какую бы ссылку выбрать... ;)

>При чём тут справка?

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

>Ну да, весь спектр функций через сигналы? Может, примеры приведёте? :)

Пайпы в консоли? ;) Или приложению кроме ввода-вывода информации и ошибок ещё что-то другое нужно?

>В KDE он это может проконтролировать в контекстном меню и воспользоваться пунктом "Открыть в...". Только непонятно, зачем нужна такая паранойя? :)

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

>Тогда давайте определимся что есть "Windows way" и в чём его отличие от "Unix way".

Википедия дает ответ. http://ru.wikipedia.org/wiki/Unix .Windows-way - наоорот: монолит, бинарные данные, гистый гуй.

>В сложных задачах - да.

Можно пример сложной задачи без корпоративного уклона?

>Речь идёт про замену операторов вывода просто текстом.

Опять по кругу? Вставляйте "просто текст" с помощью функций.

anonymous
()
Ответ на: комментарий от Skull

>Почему же, считаю, что всё объяснил. Просто вы читать не хотите.

Объяснение состоялось, если собеседник вас понял.

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

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

>На http://en.wikipedia.org/wiki/Unix_philosophy нет ни слова про backend

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

>Док-окна - это сокращение для "окон инструментов". :)

Ну вот, теперь пошли отмазки типа "док-окна вовсе не док-окна ,а окна инструментов." Может, пора правильные термины давать, а не отсебятину нести? И я конкретно не понял их отличий от те же окон гимпа в функциональном WM. Говорил же, что в Kate встроили WM, а вы всё "нет да нет"... От чего ушли, к тому и пришли...

anonymous
()
Ответ на: комментарий от anonymous

> Корпоративные пользователи меня (да и многих других) не интересуют

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

> Решить уравнеие шредингера тоже в уме можете? Или в школе вы 2+2 прогали? ;)

Нет, конечно! Так, интеграл могу решить.

> Ммм... Какую бы ссылку выбрать... ;)

Первую - http://posix.ru/desktop/desktop_select/

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

Необходимой для чего? Если для обычной работы - обеспечивает. Что касается разработки - тоже есть. Но на английском.

> Пайпы в консоли? ;) Или приложению кроме ввода-вывода информации и ошибок ещё что-то другое нужно?

Конечно. Управление его работой. То же проигрывание мультимедиа. :)

> Ладно, дам пример: как можно узнать, что происходит с той информацией, которую генерирует xmms (воспроизводит музыку) в зависимости от настроек KDE, в частности, настроек arts. Поскольку эта стандартная информация, она должна быть в стандартной справке.

help:/artsbuilder/index.html

> Википедия дает ответ. http://ru.wikipedia.org/wiki/Unix .Windows-way - наоорот: монолит, бинарные данные, гистый гуй.

Так-с, смотрим: Некоторые отличительные признаки UNIX-систем включают в себя:

> использование простых текстовых файлов для настройки и управления системой;

В KDE есть. ~/.kde/share/(apps|config)

> широкое применение командной строки;

В KDE есть: консоль доступна из многих мест, я об этом писал. И про консольный dcop - тоже.

> представление устройств и некоторых средств межпроцессного взаимодействия как файлов;

В KDE - есть. См. find ~/.kde/socket-localhost/ -type s

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

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

И после этого вы говорите, что KDE - не Unix-way? :)

> Можно пример сложной задачи без корпоративного уклона?

Конечно. Обработка фото: убрать красные глаза, подретушировать. Или прослушивание музыки по настроению. Или попереводить KDE. Или просмотреть Web.

Skull ★★★★★
()
Ответ на: комментарий от anonymous

> А если это сделает один раз умный дядя из стандартных средств, а потом вы будете пользоваться этим постоянно?

Увы, данные-то разнородны. И где мне найти такого дядю?

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

И как конфигурация может нарастить необходимую функциональность приложения Tcl?

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

Совершенно согласен! Именно поэтому KDE разбит на KPart. :)

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

Вот и имеем: KPart == backend, приложения типа Konqueror, Kate, Kwrite - фронтэнды.

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

Прошу прощения, забыл как они в справке называются. Теперь специально для вас буду сначала глядеть в справку. :)

> И я конкретно не понял их отличий от те же окон гимпа в функциональном WM. Говорил же, что в Kate встроили WM, а вы всё "нет да нет"... От чего ушли, к тому и пришли...

Запустите Kate. После этого продолжим разговор.

Skull ★★★★★
()
Ответ на: комментарий от Skull

>А вот таких линуксоидов как я - очень интересуют.

Тогда, исходя из того, отчего уходили, нужно сказать: MDI нужно для меня (то есть для Skull'а).

>Нет, конечно! Так, интеграл могу решить.

Численно? Молодцы!

>Первую - http://posix.ru/desktop/desktop_select/

И где там про динамическое управление приложениями КДЕ? Опять подмена терминов ,как и с док-окнами?

>Необходимой для чего? Если для обычной работы - обеспечивает.

Беседа с вами - обычная работа? Или специализированная? ;)

>Управление его работой. То же проигрывание мультимедиа. :)

Один из компонентов конвейера перехватывает управляющие команды и взаимодействует с потоками. Какие проблемы?

>help:/artsbuilder/index.html

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

>В KDE есть: консоль доступна из многих мест, я об этом писал. И про консольный dcop - тоже.

Доступность консоли не означает её широкого применения. Облом номер раз.

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

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

>И после этого вы говорите, что KDE - не Unix-way? :)

И после этого можно говорить что-то о КДЕ и Юних-вэй?

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

А причём здесь работа с пайпами, и тем более файлами?

anonymous
()
Ответ на: комментарий от Skull

>Увы, данные-то разнородны. И где мне найти такого дядю?

Такой дядя называется интегратор.

>И как конфигурация может нарастить необходимую функциональность приложения Tcl?

"Приложение" Tcl - это клей между стандартными средствами Unix. В зависимости от ситуации, конфигурируя это приложение, можно использовать те или иные средства. К примеру, для менеждера закачки варьировать бэкэндом (curl, wget), средствами обработки (к примеру, проверкой файлов на отсутствие повреждений), сортировки и т. д.

>Вот и имеем: KPart == backend, приложения типа Konqueror, Kate, Kwrite - фронтэнды.

А отдельно этот бакэнд использовать могу? Консольный kget, консольные части krita, quanta plus есть? Не библиотеки, а именно программы.

>Запустите Kate. После этого продолжим разговор.

Ну, вот он передо мной несколько дней крутится, красуясь отвратной подсветкой Tcl. Что дальше?

anonymous
()
Ответ на: комментарий от anonymous

> Тогда, исходя из того, отчего уходили, нужно сказать: MDI нужно для меня (то есть для Skull'а).

Для меня и миллионов бухгалтеров. :)

> Численно? Молодцы!

Почему нет?

> И где там про динамическое управление приложениями КДЕ? Опять подмена терминов ,как и с док-окнами?

Описание KDE, последний пункт преимуществ.

> Беседа с вами - обычная работа? Или специализированная? ;)

Обычная. Но не единственная. :)

> Один из компонентов конвейера перехватывает управляющие команды и взаимодействует с потоками. Какие проблемы?

А на примере можно?

> Доступность консоли не означает её широкого применения. Облом номер раз.

Приплыли! Когда нужно - консоль под рукой. Интегрированная с файл-менеджером (ну там переход по каталогам, DnD и т.п.)

> Компоненты не есть программы, которые должны решать одну задачу.

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

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

Можно. В качестве примера - компоненты Kate и VIM.

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

Это нормально работающий конвейер в GUI. И где зависимость?

> Рискну предположит, что проргаммы в КДЕ завязаны на архитектуре приложения, а не протоколов взаиможействия.

Ошибаетесь. Протокол-то есть. DCOP.

> И после этого можно говорить что-то о КДЕ и Юних-вэй?

Доводы ваши неубедительны. Что и было по пунктам изложено.

> А причём здесь работа с пайпами, и тем более файлами?

Вот именно, не при чём. Пайпы консольные не нужны. А с файлами всё и так работает.

Skull ★★★★★
()
Ответ на: комментарий от anonymous

> Такой дядя называется интегратор.

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

> К примеру, для менеждера закачки варьировать бэкэндом (curl, wget), средствами обработки (к примеру, проверкой файлов на отсутствие повреждений), сортировки и т. д.

Это актуально для любого скриптового языка (в т.ч. Kommander). Tcl тут не одинок, но сильно проигрывает по функционалу. Что доказывается его слабым распространением для прикладных задач.

> А отдельно этот бакэнд использовать могу? Консольный kget, консольные части krita, quanta plus есть? Не библиотеки, а именно программы.

Если есть клиент XWindow, то да, могут. Через DCOP. :)

> Ну, вот он передо мной несколько дней крутится, красуясь отвратной подсветкой Tcl. Что дальше?

Панели инструментов на месте (куда вы их поставили)? Выезжают/заезжают? Разницу между торчащими перекрывающимися окнами GIMP видите? :)

Что касается подсветки Tcl, то, значит, никто из снобствующих Tcl'овцев не счёл нужным поправить. :)

Skull ★★★★★
()
Ответ на: комментарий от Skull

>Для меня и миллионов бухгалтеров. :)

Миллиона бухгалтеров? В россии или в мире? Юзеров-то будет поболее бухгалтеров...

>Почему нет?

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

>Описание KDE, последний пункт преимуществ.

Ух ты, Skull, какой вы многогранный. Там, где я удовлетворюсь "управлению из консоли" вы придумаете термин, который ещё и интуитивно искать нужно. Буду знать...

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

>Обычная.

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

>А на примере можно?

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

>Приплыли! Когда нужно - консоль под рукой.

Разница между "широким использованием" и "необходимым" не ясна?

>Но как обособленные блоки вполне работоспособны.

Как обособленные библиотеки? Ещё бы, если бы их нельзя было бы использовать в таком плане, то глючности КДЕ не было бы предела. для их склеивания нужно учитывать их средства взаиможействия. Стандартными "< > | >> << & &&" тут не обойдешься.

>Можно. В качестве примера - компоненты Kate и VIM.

Один из тех немногих случаев, когда надежда ещё остаётся. А можно заменить компоненты Kget, Konqueror, или вместо vim использовать emacs а вместо arts - esound?

>Это нормально работающий конвейер в GUI. И где зависимость?

Зависимость в том, что к консольном конвейере можно заменить любую однотипную прогу на другую такого же плана, а в КДЕ нужна совместимость с КДЕ. Кроме того, конвейеры в консоли составляют программы, а к КДЕ - библиотеки и ситерфейсом dcop, а не стандартным юниховым. Пока dcop или что-то в этом роде н станет _полным_ стандартом для подавляющего большинства приложений, говорить о стандартном конвейере не приходится.

>Вот именно, не при чём. Пайпы консольные не нужны. А с файлами всё и так работает.

Вот именно, совершенно ни при чём. Пайпами такую задачу не решают. С чего вы этот пример привели?

anonymous
()
Ответ на: комментарий от Skull

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

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

>Это актуально для любого скриптового языка (в т.ч. Kommander)

Не имеет значение, я говорю об архитектуре, а не о конкретной реализации.

>Tcl сильно проигрывает по функционалу.

Бред. В своей ниже у Tcl нет равных, а для остальных используются стандартные средства Unix.

>Если есть клиент XWindow, то да, могут. Через DCOP

Я говорю про консольные варианты. Чисто консольные, а не консольные по Skull'у.

>Панели инструментов на месте (куда вы их поставили)? Выезжают/заезжают? Разницу между торчащими перекрывающимися окнами GIMP видите? :)

Опять 25. Я уже давно говорю про эти костыли к MDI, но меня не слышат. Всё, что вы перечисляете, _должно_ реализоваться методами WM, в рассматриваемом случае - Kwin, ибо это его работа - управлять окнами. А в случае с Kate функции WM встроены в редактор. То есть недостатки Kwin решили устранить, встравивая его функции в другие приложения, что есть Windows-way.

anonymous
()
Ответ на: комментарий от anonymous

> Миллиона бухгалтеров? В россии или в мире? Юзеров-то будет поболее бухгалтеров...

В России. И это весьма существенный и платежеспособный сегмент.

> Меня хватает только на аналитическое взятие интеграла. А численно вы как можете?

Приблизительное вычисление определённого интеграла.

> Там, где я удовлетворюсь "управлению из консоли"

И кто тут говорил про то, что не зациклился на CLI, поборник Unix way вы наш? :)

> Нахлобучка DCOP управляется из консоли, в то время как приложением можно управлять без неё при помощи управления бакэндом.

А чем DCOP не бэкенд? :)

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

Я вот так и понял про "трёп" и "костыли" (внимание, эти термины из сленга и их нет в справке!) :)

> Разница между "широким использованием" и "необходимым" не ясна?

Ясна. Просто GUI даёт больше свободы в решении задач, оставляя все преимущества CLI.

> А можно заменить компоненты Kget, Konqueror, или вместо vim использовать emacs а вместо arts - esound?

KGet - нельзя. Konqueror - можно использовать Gecko, Arts можно отключить и приложения будут использовать /dev/dsp (а в KDE 4 Phonon будет сплошь модульным с бэкендами xine, gstreamer и т.п.)

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

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

> С чего вы этот пример привели?

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

Skull ★★★★★
()
Ответ на: комментарий от anonymous

> Бред. В своей ниже у Tcl нет равных, а для остальных используются стандартные средства Unix.

И всё это - в маргинальном сегменте? На моей памяти было всего два приложения на Tcl (MovaTK и Tkabber), но они просто убоги по сравнению с StarDict и Kopete. Не спорю, прототипирование на Tcl производить проще, но удобный интерфейс строить для повседневного применения невозможно.

> Я говорю про консольные варианты. Чисто консольные, а не консольные по Skull'у.

Ну и какие проблемы разнести клиент и сервер XWindow? :) Я уже писал про вашу упёртость консольным CLI. Вот ещё одно подтверждение.

> Я уже давно говорю про эти костыли к MDI, но меня не слышат. Всё, что вы перечисляете, _должно_ реализоваться методами WM, в рассматриваемом случае - Kwin, ибо это его работа - управлять окнами.

Ну я думаю, мы ещё долго не дождёмся настолько удобного WM, чтобы он позволял управлять встраиванием окон, сворачиванием из до вертикальных заголовков и прочего. Впрочем, другие WM ещё хуже. Так что помечтайте про чистый Unix-way и интеллектуальный WM. Это не имеет никакого отношения к действительности. Я начну закругляться, флейм уже надоедает. Если хотите, могу признать, что везде был не прав, что KDE - монолит, несовместимый с идеальным юниксовым десктопом, а мечты сбываются, лишь бы вы флеймить прекратили. :)

Skull ★★★★★
()
Ответ на: комментарий от Skull

>В России. И это весьма существенный и платежеспособный сегмент.

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

>И кто тут говорил про то, что не зациклился на CLI, поборник Unix way вы наш? :)

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

>А чем DCOP не бэкенд? :)

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

>Я вот так и понял про "трёп" и "костыли"

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

>Ясна. Просто GUI даёт больше свободы в решении задач, оставляя все преимущества CLI.

Я что, против? Но это не юних-вей.

>Konqueror - можно использовать Gecko

Только Gecko? А если я хочу движок от lynx, к примеру?

>Arts можно отключить и приложения будут использовать /dev/dsp

При отключении arts в Центре управления, Noatun запускает этот сервер снова. И если до запуска сервера xmms может выводит звук через alsa, то после - только через arts до его убийства.

>Но никто и не стремится использовать конвейеры в GUI.

А как же ваша фраза о том, чято использование dcop и Kpatrs - типичный конвейер? Конвейер, но только половинчатый и нестандартный.

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

Пардон, но я опять не вижу способа использовать паймы. И что понимается под "работой над Html"? Анализ? Так это дело чисто парсера.

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

anonymous
()
Ответ на: комментарий от Skull

>На моей памяти было всего два приложения на Tcl (MovaTK и Tkabber), но они просто убоги по сравнению с StarDict и Kopete. Не спорю, прототипирование на Tcl производить проще, но удобный интерфейс строить для повседневного применения невозможно.

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

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

>Ну и какие проблемы разнести клиент и сервер XWindow? :)

Забудьте про XWindow. Побобные программы не должны быть зависивы от таких пакетов.

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

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

>лишь бы вы флеймить прекратили. :)

Вы давно уже могли уйти по-английски. Что же вас удерживает? Мой ответ всегда будет последним.

anonymous
()
Ответ на: комментарий от anonymous

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

Странные бухгалтера. Самоубийцы.

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

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

> Только Gecko? А если я хочу движок от lynx, к примеру?

Пишите! API открыт. :)

> При отключении arts в Центре управления, Noatun запускает этот сервер снова. И если до запуска сервера xmms может выводит звук через alsa, то после - только через arts до его убийства.

Проблемы приложений.

> А как же ваша фраза о том, чято использование dcop и Kpatrs - типичный конвейер? Конвейер, но только половинчатый и нестандартный.

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

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

А для чего тогда использовать пайпы, как не для анализа текста? Получается - ни для чего?

Что касается HTML, то помимо парсера требуется обработка, поиск, возможно - замена. Много чего.

Skull ★★★★★
()
Ответ на: комментарий от anonymous

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

Для меня он был неудобен в высшей степени.

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

Окна инструментов и не должны обладать функциональностью отдельных окон. Потому в KWin это не реализовано и ваш сарказм насчёт "наелись".

> Вы давно уже могли уйти по-английски. Что же вас удерживает? Мой ответ всегда будет последним.

Фанатизм? Да ради Бога. Просто интересно общаться с фанатиком, ненавидящим KDE. :)

Skull ★★★★★
()
Ответ на: комментарий от Skull

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

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

>Пишите! API открыт. :)

А что писать? В mc ничего писать не надо - всё совместимо и так. Так, значит, совместимости с самым стандартным браузером отсутствует?

>Проблемы приложений.

Вы забыли добавить КДЕ: проблемы приложений КДЕ.

>А для чего тогда использовать пайпы, как не для анализа текста?

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

>Что касается HTML, то помимо парсера требуется обработка, поиск, возможно - замена. Много чего.

Поиск, замена и, возможно, "много чего" - дело текстовых редакторов аля vi. Обработка - дело браузера. Tcl может использоваться для "склеивания" необходимых средств воедино.

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

Нестандарт - это дело Microsoft. Удоблетворены, что KDE пойдёт по её пути? Эта фирмочка тоже не любит использовать стандарты.

anonymous
()
Ответ на: комментарий от Skull

>Для меня он был неудобен в высшей степени.

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

>Окна инструментов и не должны обладать функциональностью отдельных окон.

Как это "не должны", когда облаадают - их можно двигать и менять размеры. Всё! Это - функциональность WM, которая реализована в Kate вместо Kwin. Именно "наелись".

>Просто интересно общаться с фанатиком, ненавидящим KDE. :)

Странное предложение. Если интересно ,что чего-ж "только бы вы флеймить перестали"? ;) Кроме того, я не ненавижу KDE - иначе я молчал и недостатки не обсуждал - а зачем?

anonymous
()
Ответ на: комментарий от anonymous

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

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

> А что писать? В mc ничего писать не надо - всё совместимо и так. Так, значит, совместимости с самым стандартным браузером отсутствует?

А где совместимость с Gecko и KHTML? Да и где links?

> Вы забыли добавить КДЕ: проблемы приложений КДЕ.

С каких пор XMMS стала приложением KDE? :)

> А вообще ,странный вопрос, для чего - для автоматизации автоматизирующихся задач

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

> Поиск, замена и, возможно, "много чего" - дело текстовых редакторов аля vi.

А если много файлов? Кто тут рассказывает мне про Unix-way?

> Обработка - дело браузера.

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

> Tcl может использоваться для "склеивания" необходимых средств воедино.

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

> Удоблетворены, что KDE пойдёт по её пути? Эта фирмочка тоже не любит использовать стандарты.

Хотите поговорить о стандартах. Ну давайте. Только учтите, что эот стандарты уровня ГОСТ и ISO. Даже RFC уже не стандарты, а перечисленные вами инструменты и подавно. Я же вас предупреждал - осторожнее с терминами. :)

Skull ★★★★★
()
Ответ на: комментарий от anonymous

> Подмена понятий. Непривычен. Неудобство - следствие отсутствия опыта работы с ч-либо.

Ничего подобного! Хотите обсудить сокращение усилий при показе всплывающих окон? Не путайте эффективность с привычностью.

> Как это "не должны", когда облаадают - их можно двигать и менять размеры. Всё! Это - функциональность WM, которая реализована в Kate вместо Kwin. Именно "наелись".

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

> Если интересно ,что чего-ж "только бы вы флеймить перестали"?

Потому как надоело читать откровенную нелепицу. :)

Skull ★★★★★
()
Ответ на: комментарий от Skull

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

Как раз такие проблемы и должны решать интеграторы.

>А где совместимость с Gecko и KHTML? Да и где links?

Как вы представляете показ этими движками в текстовом режиме? А с Links есть проблемы?

>С каких пор XMMS стала приложением KDE? :)

А, так вы о XMMS. Так в чём его проблема? В том, что автоматически звуковой сервер не определяет? А вот у Noatun проблема есть - вывод только через arts.

>о есть для задач, которые до появления компьютеров не возникали?

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

> если много файлов?

sed? Описание вашей задачи очень расплывчто. Может, дадите больше данных?

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

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

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

>Только учтите, что эот стандарты уровня ГОСТ и ISO.

ISO, насколько я знаю, является лишь рекомендацией. ГОСТы существуют не на всё. Поэтому в качестве стандарта учитывается прежде всего то, что использовалось двольно продолжительное время. В частности, архитектура Unix в Linux. Говорим про пайпы, юних-вей и CLI.

anonymous
()
Ответ на: комментарий от Skull

>Ничего подобного! Хотите обсудить сокращение усилий при показе всплывающих окон?

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

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

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

>Потому как надоело читать откровенную нелепицу. :)

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

anonymous
()
Ответ на: комментарий от anonymous

> Как вы представляете показ этими движками в текстовом режиме? А с Links есть проблемы?

Нет, но надо настривать. К тому же Links сейчас везде заменяет Lynx. Это к вопросу о стандартах. :)

> sed? Описание вашей задачи очень расплывчто. Может, дадите больше данных?

Пример - поиск по множеству po-файлам. И как мне Vim поможет? Я к тому, что vim изначально предназначен для редактирования. Непонятно, почему вы о нём вспомнили. :)

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

Для вас сложно понять, как котировки вытаскиваются с веб-страниц и помещаются в базу? Так чего бы стараетесь втирать мне про консоль и Unix-way, если на таких вещах банальных стопоритесь?

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

А это что, не распространённое действие? Как раз делается стандартными конвейерами. Я уже перешёл на обсуждение чисто консольных задач, а вы и здесь безграмотность показываете. Что, дальше "сферического коня в командной строке" не можете ничего обсуждать? :)

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

Вот в том то и дело, что на домашнем компьютере CLI нафиг не упёрлась. Примеров приводил массу.

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

Сами за уши определение притянули? :)

Skull ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 →
Linux General