Здравствуйте, Cyberax, Вы писали:

C>По странному совпадению, МСОффис безглючнее своих конкурентов.

(плотоядно потирая кулаки) Ага, щасс...
Буквально вот на днях. Есть .doc файл с вот такой растровой картинкой (откуда она взялась — не важно, скажам дали):


Элементарная задача. Требуется отредактировать картинку и заменить все надписи типа "Style=1,2,3..." на "Style=A,B,C...". Как это делается? В первую очередь пробуем банально замазать встроенным редактором и сделать новые надписи (точное соблюдение шпифта не требуется). И тут же обнаруживаем, что при выборе цвета отсутствует простейшая функция "Pick Color" и выставить в точности цвет очень непросто. Хорошо. Берем другой способ — copy/paste плюс MS Paint. Копируем изображение, вставляем его в Paint и получаем следующую порноту:


Ну вот какой кретин решил, что при копировании надо портить картинку и приводить ее к стандартным 256 цветам поносного цвета?! И это Это Office 2003! Они наверное думают, что 256 цветов — это неимоверно круто.

---

И так во всем. Другой пример. Есть некая презентация в PowerPoint. Фрагмент выгдядит так (градиентный фон не важен):

---

Селектируем его и копируем в Word. Результат:

Куда линия подевалась? Куда текст отъехал?

---

В Exel:

Та же беда, формально чуть лучше.

---

В MS Paint:

Самый адекватный результат, но опять-же, 1) цвета "отъехали" 2) пропало сглаживание шрифтов.

---

Пробуем сгруппировать выделеные элементы и снова скопировать всю группу в Word:

Прогресс! Линия появилась! Отдельная благодарность за оригинальную трактовку наклонного текста. Очень смешно — "упал пац стол"...

---

Так каков правильный способ copy-paste? Вот именно — сделать screenshot, после чего с помощью Paint вырезать нужный фрагмент и вставить его как битмап. Собственно на этом так называемые "безграничные возможности" буфера обмена и заканчиваются.

Может я чего-то не понимаю, но меня от подобной халтуры тошнит. Как вся эта помойка может нравиться, я тем более не понимаю. Ребята! Брынза не бывает зеленого цвета — это вас кто-то обманул.

Здравствуйте, Cyberax, Вы писали:

C>По странному совпадению, МСОффис безглючнее своих конкурентов.

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

>> Каждая программа должна делать свое дело.
C>Именно. Word редактирует документ, Excel редактирует таблицы и т.п.

И не фиг их смешивать.

Правда, с другой стороны, Unix way ну нисколечко не мешает сделать такой (пусть и совершенно ненужный) GUI. См., к примеру, wxMaxima.

>> А в третей все должно интегрироватся.
C>Как?

См. мой пример.

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

Идиотизм.

C>Просто с OLE произошло все то, что происходит с продуктами MS — "хотели
C>как лучше, а получилось как всегда". Вместо compound documents можно
C>было бы использовать простые zip-файлы (как в OO), вместо моникеров —
C>обычные URL. И тогда OLE выглядел бы намного приятнее.


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

Здравствуйте, Kisloid, Вы писали:

K>Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET. Знаю под линуксом есть мозилловская разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает до COM по качеству, скорости. Может я чего то упустил ?

А кто сказал, что COM и .Net — компонентные технологии?
Они обе завязаны на реестр и Windows. Даже в Mono сталкиваются с неожиданными трудностями по реализации точка-нет, не говоря уже о реализации COM на не-MS-платформах. Эти т.н. "компонентные технологии" не являются таковыми, так как компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают.

В Linux компонентно всё: от ядра до процессов пользовательского уровня. Например, оконная система X Window работает с ядром и пользовательскими процессами по чётко специфицированным протоколам, позволяющим запускать пользовательские процессы на одном компьютере, а следить за ним с красивым GUI на другом компьютере. Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.

P.S. В GNOME Desktop Environment штатно работает ORBit — CORBA сервер — аналог поддержки OLE/DCOM в Windows.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Kolhoz, Вы писали:

K>> А вообще я не понимаю, к чему это?

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

А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.

Здравствуйте, Kisloid, Вы писали:

K>Может я чего то упустил ?

Да, Unix way: Basics of the Unix Philosophy (в особенности Rule of Modularity: Write simple parts connected by clean interfaces, Rule of Composition: Design programs to be connected with other programs, Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do), Multiprogramming (в особенности Problems and Methods to Avoid) и, главное, The Unix Philosophy in One Lesson.

Здравствуйте, Quintanar, Вы писали:

Q>Так поднапрягите воображение. На COM и .NET мир клином не сошелся.
Q>У программистов Windows есть понятная склонность считать технологии МС верхом человеческой мысли. А то, что эти технологии меняются как в калейдоскопе их не заботит. Unix консервативен, в его мире книги Стивенса, вышедшие в начале 90-х, до сих пор сохраняют свою полезность и эта консервативность не мешает делать крупные проекты.

Забавно, что есть много слов. Даже трое согласных с ними. И ни грамма по КОП.

Здравствуйте, Kolhoz, Вы писали:
K> Вообще, странные вы люди, вендузятники. Кроме как про "документы" ни про что иное и думать не в состоянии. Ваш мирок ограничен "офисом".
А хоть бы и ограничен. Давай ты, как нестранный юниксоид, предожишь нормальный способ делать компаунд-документы. Декларации о "совершенной ненужности" свойственны людям, которые вообще не ориентированы на потребителя. Если потребителю надо иметь докмент, в котором сведен текст+векторная графика+растровая графика+таблицы+диаграммы, то не надо апеллировать к plain-text RFC. Ну вот надо ему это, и все!
И при этом желательно чтобы это было WYSIWYG. Просто потому, что это не просто документ, а плод очень большого объема размышлений. И у пользователя нет ни времени ни желания исследовать шаманство вроде TeX, чтобы только выяснить, как ему добиться одинаковой высоты текстового заголовка и графического логотипа. В 10000 раз быстрее подвинуть границы мышкой.
Это ваш мирок ограничен нердами, которые вообще себе не представляют, что у людей могут быть и другие потребности, кроме как гонять символы по пайпам или тащиться от того, что кастомизированный фраунгофер жмет на 0.4% быстрее стандартного. Людям надо быстро поправить брошюру и отдать ее в типографию, а потом бежать домой удовлетворять потребности из пирамиды Маслоу. Не надо кичиться своей нердностью. Она вполне хороша на своем месте, среди других нердов.

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

Здравствуйте, Kisloid, Вы писали:

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

Так поднапрягите воображение. На COM и .NET мир клином не сошелся.
У программистов Windows есть понятная склонность считать технологии МС верхом человеческой мысли. А то, что эти технологии меняются как в калейдоскопе их не заботит. Unix консервативен, в его мире книги Стивенса, вышедшие в начале 90-х, до сих пор сохраняют свою полезность и эта консервативность не мешает делать крупные проекты.

K>Странные люди. Не освоился я тут ещё, в общем.

Это нормально Пару месяцев наблюдения за/участия в, и с человеком происходит одно из двух:
— или подсаживается на Священные войны, как наркоман, и сам будешь кричать на всех направо и налево
— или спокойно начинает наблюдать за баталиями, похихикивая над оппонентами, и выискивая в бурных спорах крупицы истины (увлекательнейшее занятие, скажу)

VladD2 wrote:
>> > Извини, но это руки.
> C>Спорим?
На что спорим?

> C>Правая синтетика — инкрементальная перестройка проекта BJam'ом на
> C>Линуксе работает в десять (десять!) раз быстрее. Как показал профилятор
> C>- большая часть времени в Винде тратится на stat()'инг файлов.
> Я не знаю что такое BJam и не знаю что такое stat().
BJam — это Boost.Jam. Инструмент для постройки проектов, он при запуске
производит сканирование зависимостей.

stat()'инг — вызов функции stat(), которая берет информацию о файле
(даты изменения, размер, атрибуты).

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

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

> C>Да? Вот покажи мне как в этих замечательных сменяемых FS добавить
> C>поддержку безопасности и возможность загрузки с них.
> Загрузка происходит с МБР, а что до безопасности то тебе вроде скорость
> нужна была.
Как мне загрузить систему со своей FS? Даю наводку — это еще ни у кого
не получилось в полной мере.

Безопасность мне нужна ВМЕСТЕ со скоростью. Reiser4 в Линуксе мне дает
скорость, безопасность И транзакционную целостность FS (а NTFS этого,
кстати, не гарантирует).

> А по жизни НТФС всем хватат за глаза.
Так как 99% ничего кроме NTFS и FAT и в глаза не видели.

> Потому никого
> твоя пенисометрия не колшит. В Линуксе 99.9% тоже ставя то что идет по
> умолчанию и не выпендриваются.
Да ну? То-то идиоты разрабатывают Reiser4, XFS и прочие никому не нужные
вещи (кстати, Debian при установке по дефолту Reiser3 ставит).

> И вообще зря я стобой снова спорить влез. Речь шала о доступных под ОС
> возможностях. Сменяемые файловые системы это баловство для очень
> посвященных. А вот наличие МС Сиквела, Фаркрая, Винкомандера, Студии с
> дотнетом... она совсем не заменяет.
Ага. Главное чтобы был .Net, Пасьянс и MS SQL. Больше никому ничего не
надо.

Спасибо, ты открыл мне глаза.

Здравствуйте, Kisloid, Вы писали:

K>Надо признать, что реализация у МС хромает. Но давайте рассмотрим опять этот злосчастный .NET, у которой тоже реализация подхрамывает Для меня важна философия, архитектура, документация, перспективы итд, а баги это не самое главное.

Я уже приводил свое видение рекламного слогана для дот-нет:



Аналогично для MS Office:


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

Kisloid wrote:

> Вот мне очень интересно. Есть ли под линуксами компонентно
> ориентированное программирование ? Исходя из личного опыта, не могу себе
> представить крупный проект без компонентно ориентированного подхода. Под
> windows например COM, .NET. Знаю под линуксом есть мозилловская
> разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает
> до COM по качеству, скорости. Может я чего то упустил ?
Мои пять копеек. Имхо идеология Линукс в принципе не озабачивается этим, как операционная система оно не хочет
"ограничивать" пользователей одной технологией, как это делает майкрософт.
Т.е. сама идеология — конструктор "собери-сам", майкрософт же пытается всё запихать в операционку.
Если тебе понадобится выбрать КОП платформу — пожалуйста, java, mono, corba, XPCOM, SOAP, всё что угодно. Линукс —
прежде всего операционная система, притом действительно многоплатформенная.
В общем, Линукс ОС и КОП — вещи перпендикулярые, что хочешь, то прилаживаешь, а КОП в Виндоуз ОС — фактически
неотъемлимая часть.
Спор о том, что более правильное — спор ни о чём, это два решения одной задачи, и оба верные.

Здравствуйте, DJ KARIES, Вы писали:

DK>Дело в том, что распростанённость этого чуда весьма низка...

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

DK>Отсюда мораль, выживает тот, кто выживает (кого-то). (тобишь мелкомягкие)

А что, с X-Window что-то случилось? Вроде бы очень даже неплохо выживает. Что бы там всякие малограмотные не вещали.

Здравствуйте, Cyberax, Вы писали:

>> Не пайпом единым... Открываем кого либо через popen(), и общаемся в обе
>> стороны.
C>А все равно. Нет нормального механизма передачи исключительных ситуаций.

Как нет? Оно обычно в протокол зашито. Ни разу с этим трудностей не испытывал.

>> C>2. Или ограниченность простыми текстовыми данными, или необходмость
>> C>парсить данные в каждой программе.
>> Это ни фига не недостаток. Это огромнейшее преимущество!!!
C>Недостаток. Кроме простого текста есть:
C>1. XML

Это — простой текст. Только очень дерьмовый простой текст. У меня всегда практически для обмена структурированной информацией S-выражения используются.

C>2. JSON
C>3. Да хотя бы ini-файлы
C>4. Файлы с многострочными значениями

И? Где тут проблемы, а?

C>Какие стандартные утилиты догадаются, что последовательность &#3241 (код
C>вымышлен) — это буква "а"? Правильно, никакие.

Unix-way не завязан на "стандартные" утилиты. Никак.

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

>> C>4. С бинарными данными еще хуже.
>> Да? tar -xf — бла-бла-бла | bzip2
C>А как там у нас grep будет работать, например?

А зачем для бинарных данных grep?

C>Кстати еще минус — отсутствие методов работы с непотоковыми данными. То
C>есть "cat somefile | rar | mail ..." уже не сделать — так как
C>rar'у нужен произвольный доступ для создания solid-архивов.

Ну так убогий rar — не unix way, он просто не вписывается. Любая компонентная система требует от компонентов следования определённой идеологии (и хорошо если идеологии, а не фиксированному API).

C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
C>случае в юниксах эта задача не решается).

ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной
силой.

C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?

Обе эти убогонькие программульки никакого отношения к unix way не имеют. А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в одну систему, и, как показывает практика, вендовозные ламеры, любители поредактировать табличку в текстовом процессоре, по эффективности работы просто рядом не валялись с теми кто пользуется подобной связкой. Пара дней — и идеального полиграфического качества статья готова, с идеальными графиками и достоверно проверенным качеством вывода и рассчётов. Вордописцы будут с тем же самым возиться не меньше месяца, как, опять же, демонстрирует та же самая практика.

C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее
C>эффективно решать большую часть административных задач. Только
C>вот пора бы уже что-то новое придумать.

Те же самые пайпы ИДЕАЛЬНО решают задачу построения любого, сколь угодно сложного GUI. И все эти "объектно-ориентированные" решения из просто рядом не валялись с простым и элегантным решением в стиле unix way.

Здравствуйте, Cyberax, Вы писали:

C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?

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

Здравствуйте, Cyberax, Вы писали:

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

???

Ни разу не проблема.

>> Это — простой текст. Только очень дерьмовый простой текст. У меня всегда
>> практически для обмена структурированной информацией S-выражения
>> используются.
C>S-выражения — те же яйца, вид в профиль.

Не те же. Обработка проще и дешевле. И вместе с ними можно передавать код,
не только данные.

C>Как-то надо было сделать простую вещь — взять XML, пробежаться по всем
C>узлам с заданым путем, взять у них атрибут, сделать операцию с этим
C>атрибутом (это было имя файла, надо было regexp'ом его переименовать), а
C>потом записать его же в этот документ, но по другому пути.

И? Где трудности? Вставить в пайплайн xslt кто запретил?

C>После часа мучений с tee и прочими гадостями — просто взял
C>ActivePython+MSXML и за 10 минут написал все что нужно.

И чем же это не unix way?

>> C>2. JSON
>> C>3. Да хотя бы ini-файлы
>> C>4. Файлы с многострочными значениями
>> И? Где тут проблемы, а?
C>Неудобно использовать стандартные утиллиты.

Этих стандартных утилит — вагон. На все случаи жизни хватит. Для меня самые "стандартные" — perl и python.

C>Без стандартных утиллит — получается простая идеология использования
C>соединенных фильтров.

Это и есть unix way. Много маленьких уединённых программок с CLI, способных общаться через пайпы И СОКЕТЫ.

>>> > C>4. С бинарными данными еще хуже.
>>> > Да? tar -xf — бла-бла-бла | bzip2
>> C>А как там у нас grep будет работать, например?
>> А зачем для бинарных данных grep?
C>А что, бинарные данные надо распечатывать и на стенки вместо обоев вешать?

Ответ не в тему. Зачем для бинарных данных grep? Есть много других полезных утилит.

C>Нет. Это убогий unix way — так как RAR поддерживает создание архивов с
C>кодами коррекции ошибок (если повреждается часть файла — ее можно
C>восстановить). Но для этого ему нужен произвольный доступ к источнику и
C>результату.

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

>> ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной
>> силой.
C>Покажите мне fseek на named pipe или domain socket.

Зачем?

C>Можно использовать shmem с некоторыми ограничениями, но все равно не
C>хватает возможности полноценно реализовать свой файл.

Зачем? Тем более shmem не масштабируется, так что фтопку.

>> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
>> C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
>> Обе эти убогонькие программульки никакого отношения к unix way не имеют.
C>Ага, конечно. "Факты не совпадают с теорией — тем хуже для фактов".

Какие факты? Есть две ущербные программульки, про unix way ничего не знающие — так какое они имеют отношение тогда к обсуждаемой теме?

>> А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в
>> одну систему, и, как показывает практика, вендовозные ламеры, любители
>> поредактировать табличку в текстовом процессоре, по эффективности работы
>> просто рядом не валялись с теми кто пользуется подобной связкой.
C>Пробовал.

Плохо пробовали. Неумело.

C> ОЧЕНЬ неудобно писать спеки — если в Word/OpenOffice/... я
C>могу запустить редактор, нарисовать нужную диаграмму, cut&paste'ом
C>вставить в документ (не волнуюясь при этом об именах файлов), то с TeXом
C>один ужас получается.

Какие такие спеки?!? Для тех. документации есть docbook. А тех, кто пишет её в офисах — надо гнать в три шеи, им в IT не место.

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

Ну ну. Не умеете вы этих кошек готовить.

>> Пара дней — и идеального полиграфического качества статья готова, с
>> идеальными графиками и достоверно проверенным качеством вывода и
>> рассчётов.
C>Понимаете, мне НАФИГ НЕ НУЖНЫ документы полиграфического
C>качества, так работа идет с электронными копиями (а печатаются они для
C>отчетности).

Тогда какие на хрен вордоофисы? Это задача для docbook.

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

Естественно рисуют.

C>Хотя в TeXе очень неудобно писать химические формулы (точнее, их вообще
C>неудобно как-либо в текстовом виде записывать).

Удобно, очень удобно. Удобней чем любой визуальный редактор.

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

>> Те же самые пайпы ИДЕАЛЬНО решают задачу построения любого, сколь угодно
>> сложного GUI.
C>ROTFL.

Это вы от незнания.

C>Как раз GUI — это идеальный пример для "компонентов" в понимании
C>COM/.NET/Delphi.

Отвратительный пример.

Идеальный GUI — это, например, Tcl/Tk, с частичной генерацией кода на стороне логики. Другой вариант — сервер, отображающий визуальные компоненты, которые описываются в виде XML или S-выражений.

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

>> И все эти "объектно-ориентированные" решения из просто
>> рядом не валялись с простым и элегантным решением в стиле unix way.
C>Вы LOR читаете? Очень фанатичный стиль похож...

Я ROTFL читаю и смеюсь.

Нет тут фанатизма. Есть знания и опыт, которых нет у вас.

Здравствуйте, Sinclair, Вы писали:

>И у пользователя нет ни времени ни желания исследовать шаманство вроде TeX, чтобы только выяснить, как ему добиться одинаковой высоты текстового заголовка и графического логотипа. В 10000 раз быстрее подвинуть границы мышкой.
S>Это ваш мирок ограничен нердами, которые вообще себе не представляют, что у людей могут быть и другие потребности, кроме как гонять символы по пайпам или тащиться от того, что кастомизированный фраунгофер жмет на 0.4% быстрее стандартного. Людям надо быстро поправить брошюру и отдать ее в типографию, а потом бежать домой удовлетворять потребности из пирамиды Маслоу. Не надо кичиться своей нердностью. Она вполне хороша на своем месте, среди других нердов.

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

Здравствуйте, Sinclair, Вы писали:

VD>>Короче, Колхоз в отпуске на месяц.
S>И уже давно. Напоминаю, что бан-лист можно не только писать, но и читать

Это... чукча — издатель.

Здравствуйте, eao197, Вы писали:


E>Извините за личный вопрос, но не могли бы вы чуть приоткрыть маску? По вашим постам складывается впечатление, что вы являетесь аспирантом в каком-то продвинутом профильном ВУЗе (об этом говорит, например, опыт общения с LaTeX (в том числе и по набору формул), упоминание использования пакета Matematica, теперь вот упоминания про формальные доказательства и теоритические обоснования).

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


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

Грешен, грешен, допускаю иногда категоричность в экспериментальных целях — посмотреть реакцию оппонентов. Но тут стараюсь этого избегать, нервные все какие-то, самые нейтральные темы вызывают бурю эмоций. Заговоришь о применении дао unix way в программировании под Windows — как сразу кричат про linux на десктопах и про то что windows рулит, хоть это к теме и не относится. Странные люди. Не освоился я тут ещё, в общем.

E>Конечно я не в праве просить от вас подобных сведений, но все же если бы вы чуть рассказали о себе (например, образование, наличие/отсутсвие ученых степеней, предметные области, в которых вам доводилось работать), то это позволило бы лично мне определить уровень доверия к вашим высказываниям. Не обижайтесь, пожалуйста, ничего личного.

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

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

Здравствуйте, Mamut, Вы писали:


M>Все так. Только в Web'e весь этот workflow вокруг UI и вертится Специфика

е-а. Workflow всё же первичен. UI рождается уже на основе анализа workflow. Когда это делается в обратном порядке — нежданчики случаются. Ну да вы наверняка в курсе, такие нежданчики в каждом проекте были, после чего всем становилось ясно (задним умом все крепки), что надо было формальнее к проектированию подходить, и дизайнерам покрепче ручки выкручивать.

Скучно. Займёмся подъёмом трупов!

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Kolhoz, Вы писали:
K>> Вообще, странные вы люди, вендузятники. Кроме как про "документы" ни про что иное и думать не в состоянии. Ваш мирок ограничен "офисом".
S>А хоть бы и ограничен. Давай ты, как нестранный юниксоид, предожишь нормальный способ делать компаунд-документы.

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

Итак, о документах. Тут у меня достаточно богатый опыт. Я писал статьи. Я писал книги. В них было много формул, графиков, были и участки кода на разных языках. Многие элементы текста были взаимосвязанны. Параметр, получаемый при минимизации одной функции, был темой целой главы и, естественно, входил во многие вычисления и отражался на графиках. Он менялся — пока писалась статья, появлялись новые экспериментальные данные, да и я в численных алгоритмах ошибки исправлял... Я НЕ ПРЕДСТАВЛЯЮ, как это всё влезло бы в ВИЗИФИНю. Это невозможно!

S> Декларации о "совершенной ненужности" свойственны людям, которые вообще не ориентированы на потребителя.

Я ориентирован. На отборного потребителя. Умного, образованного.

S> Если потребителю надо иметь докмент, в котором сведен текст+векторная графика+растровая графика+таблицы+диаграммы, то не надо апеллировать к plain-text RFC. Ну вот надо ему это, и все!


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

S>И при этом желательно чтобы это было WYSIWYG.

Только не WYSIWYG! Зачем бедного пользователя отвлекать от сути деталями разметки? Знаете, я ставил эксперименты: давал неподготовленным пользователям latex (+ make, gnuplot, mathematica и много чего ещё), другим давал Word, Excel и прочий отстойный быдловский ширпотреб. Первые гораздо быстрее осваивались — порог вхождения по методу "monkey see — monkey do" очень невысок, маленький текстовый файлик быстро заполняется конспектом типичный конструкций — и вуаля, продвинутый ТеХник готов. С Вордом было хуже. Никто не мог запомнить, что там у него в его уродских, нелогичных менюшках. Никто не мог адекватно записать простейший макрос. Было очень много тупой, ручной работы. Было тошно.

S> Просто потому, что это не просто документ, а плод очень большого объема размышлений.

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

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

Практика показывает, что в WYSIWYG системах на то же самое, при условии изучения с нуля, уходит ГОРАЗДО больше времени.

S> В 10000 раз быстрее подвинуть границы мышкой.

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

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

Это ваши больные, ущербные, убогие представления. Ничего общего с реальностью не имеющие. Мои подопытные пользователи TeX-а — это экономисты, биологи, филологи, переводчики, физики, программисты (самого низшего звена, даже PHP-шники попадались), секретарши без высшего образования. Лучшие, конечно же, это полиграфисты — те и вовсе всё на лету схватывали, и потом кривились от отвращения при каждом упоминании WYSIWYG.

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

Мои ТеХники бегут домой гораздо быстрее чем твои по башке стукнутые тупые вордописцы.

Здравствуйте, Kisloid, Вы писали:

K>Почему нет нормальной системы установки софта ? Раз линуксоиды такие умные, почему им этого не сделать ?

Давай сравним MSI с распостраннённым на линуксах системой RPM. Сколько у тебя программ под Windows установлено? У меня MSI насчитал 163 пакета. А на Федоре у меня стоит 1079 пакетов (у меня дисковое пространство под линукс ограничено, а то бы ещё больше было). Разница на порядок. Причём подавляющее большинство зависит друг от друга. В MSI системе, в отличие от RPM, все пакеты независимы, и то MSI с трудом ими управляет. Тормоз он завидный. А если бы под Windows каждый кому не лень выпускал пакеты, которые зависят друг от друга (а не копируют каждую библиотеку себе в дирректорию — запусти "dir mfc* /s" у себя в program files), то MSI бы уже давно загнулся. Кто ещё помнит дыру в gdiplus.dll и ту тулзу, которую Microsoft написал, чтобы копии gdiplus.dll на компьютере разыскивать (и даже не исправлять, а просто предупреждать, потому что исправить их было нельзя с практической точки зрения)? Это всё недостатки MSI. А такого понятия, как репозитории под Windows вообще нет.

Kolhoz wrote:
> Короче, недостатков этой модели я не вижу. Преимуществ — вагон.
Нет недостатков???? Их куча!

1. Невозможность нормального "обратного" общения. Программы в пайпах не
могут нормально передать информацию "выше" по цепочке.
2. Или ограниченность простыми текстовыми данными, или необходмость
парсить данные в каждой программе.
3. Плохая совместимость со структурированными данными.
4. С бинарными данными еще хуже.
И т.п.

Kluev wrote:
> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
> C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
> Порочный подход. В результате получится только глючная помойка, как
> микрософис.
По странному совпадению, МСОффис безглючнее своих конкурентов.

> Каждая программа должна делать свое дело.
Именно. Word редактирует документ, Excel редактирует таблицы и т.п.

> А в третей все должно интегрироватся.
Как?

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

Просто с OLE произошло все то, что происходит с продуктами MS — "хотели
как лучше, а получилось как всегда". Вместо compound documents можно
было бы использовать простые zip-файлы (как в OO), вместо моникеров —
обычные URL. И тогда OLE выглядел бы намного приятнее.

Здравствуйте, Cyberax, Вы писали:

C>Мальчик, файл и VFS в юниксах — это классический пример объектного
C>дизайна. VFS — так это вообще textbook example для полиморфизма.

Дедушка, эта ваша фраза — типичный пример так называемого передёргивания, каковое является частным случаем так называемой демагогии.

>> И реализован он будет через временный файл. Оно нам надо?
C>Нет. Реализован он может быть как угодно. Лично делал IStream поверх
C>DB-блоба.

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

Здравствуйте, Cyberax, Вы писали:

>> Ты научись сначала понимать, что люди говорят. Ты же русским языком не
>> владеешь! И эта конкретная ветка — тому пример. Я про одно — а ты и
>> подпевалы — совсем про другое. Даже умудрился где-то углядеть якобы
>> "презрение к пользователям Windows".
C>Было, было. В частности про виндузятников с узким кругозором.

Из контекста было совершенно ясно, что виндузятники — это сторонники genuine windows way. Простых смертных юзеров мы в разговоре вообще не касались. А кругозор ведь и в самом деле узкий — о чём ни начинай разговор, а всё документами закончится. Это, собственно, windows way и есть — всё есть документ, а что не документ, то папочка, и вообще, закройте глаза, дышите глубже, представьте себе тяжелый кондовый такой конторский стол... Представили? Медитируйте на него!

Здравствуйте, Kolhoz, Вы писали:

K> А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.

Видите, с какими противоположными взглядами здесь общаются люди. Если мне школьник скажет, что на небе 102346234846 звезд, то для меня это будет совершенно непроверенная информация. Если же это число скажет профессор-астроном, то я с большой вероятности приму это значение на веру. Хотя бы потому, что я могу сослаться на этого профессора. Или же описание механизма исключений в C++ я предпочту прочитать в книге Страуструпа, а не в "Освой C++ самостоятельно за 21 день".

Кстати, анекдот в тему:

Беседуют два профессора. Один говорит:
-- Вы представляете, коллега, если сказать кому-нибудь, что на небе 102346234846 звезд, то 99.9% людей в это тут же поверят. А вот стоит повесить на скамейку табличку "Осторожно, окрашено", то все обязательно будут проверять это пальцем.

Извините, если мой вопрос показался вам не корректным. Давно я уже тут, параноя, знаете ли

Здравствуйте, VladD2, Вы писали:

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

VD>Цитаты, плиз, а мы оценим адекватны ли твои выводы.
Кто такие "мы"? Или ты о себе во множественном числе?
EnterpriseServices:
At this point Mono does not support the EnterpriseServices namespace.
System.Windows.Forms:
The current implementation is still somewhat incomplete, with several large controls (Edit, ListBox/ComboBox, TreeView), etc, still being developed. It is too early to file bugs if you cannot compile or run a certain application because of controls missing.
Unsupported technologies
Some technologies are very hard to implement or are being phased out by components in the Longhorn time frame. In some cases, we feel that they are not crucial to the future of the open source desktop.

System.EnterpriseServices and System.Management come to mind, and we are unlikely to put any resources into the task. We would gladly host the code if someone cares to implement it, but they would likely remain unsupported features of Mono.

А по поводу пробовал/не пробовал — я заводил rotor под FreeBSD как только он был анонсирован, поэтому представление имею.
А вот ты пробовал mono под Linux? или ты настолько наивен, чтобы верить всему, что пишут на сайтах разработчики?

VD>Serviced Components никогда не входило в состав BCL. Более того Serviced Components — это обертка над COM+, который реализован только под Windows 2000+.
Serviced Components входят в .NET Framework, а уж что это и с каких версий винды поддерживается совершенно не важно, непонимаю к чему ты приводишь эту соверщенно несущественную в данном контексте информацию.

EC>> И они смогут участвовать в распределённых транзакциях?
VD>Насколько я понимаю для этого можно использовать библиотеки вроде Кибернэйта.
Ты неправильно понимаешь — я про транзакции, что поверх DTC работают. В MS реализации .NET Framework это есть, а в моно болт.
Я говорю именно об этом — 2 реализации совершенно неравномощны в плане функциональности, а все разговоры о стандартах это для пионеров.

EC>>Для тех, кто не читает между строк — основная мысль моего поста такая: большинству пользователей среды не нужен её кастрированный вариант.
VD>Большинству людей не нужен сам Линукс. Что с того?
Ты опять не посуществу: как это относится к той теме, о которой я говорил?

VD>В общем, еще раз не притягивай за уши вещи к делу не относящиеся. Ява и Моно прекрасно решают проблему компонентрой разработки. А уж применимость их для решения конкретных задач — это отдельный вопрос.
Ещё раз, для тех у кого в танке сильно накурено, я овечал на конкретную фразу из сообщения Еще посмотрим, когда Mono доделают как он на Unix системах развернется.

Автор: Андрей Хропов
Дата: 22.06.06

Я выразил сомнение в том факте, что моно когда-либо развернётся на юнихах, так же как под виндой, про компонентный подход в линукс вообще ни слова.
Но тут пришёл ты, со своей туманной философией, странно ещё, что про Nemerle ничего не сказал.
Т.е. я, например, не верю, что можно завести RSDN@home под моно на линухе и дело даже не в отсутствии Jet.
Думаю с этим ты спорить не будешь?
В общем все твои посты, не относящиеся к теме того поста, на который я отвечал я буду просто скипать.

Здравствуйте, Kisloid, Вы писали:

E>>Да, Unix way: [skipped]

K>Вот тогда следующий вопрос, возьмем к примеру Мозилловские проекты, зачем им надо было создавать свою реализацию КОМа если есть unix way (хотя наверное вопрос к ним ) ?

Может быть из-за того, что Mozilla (изначально Netscape) не является типично unix-овым проектом. Он пытается внести в Unix поведение Windows. Аналогичные попытки сделать какую-то компонентность для GUI есть в KDE. Называется KParts.

K>Какие примеры больших проектов написанных исключительно через unix way ? GAIM ?

С GIMP-ом и GAIM-ом не знаком, поскольку не пользовался. Но вот в качестве примера можно вспомнить Subversion, который способен использовать ssh для организации защищенного доступа к репозиториям. А так же svnadmin dump, который выплевывает содержимое репозитория в виде теста на стандартный вывод. Что позволяет интегрировать его с разными инструментами в виде архиваторов, фильтров и прочего. Либо почтовый клиент Mutt, который использует внешний текстовый редактор для редактирования почты. А так же разные преобразователи форматов, входящих в состав TeX-а.

Что касается удобства, то, имхо, нужно разделять Server-Side приложения и GUI приложения. В server-side приложениях Unix way весьма удобен. GUI, из-за того, что пользователи привыкли к Window-ому OLE, пытается придумывать какие-то комбайны.

Здравствуйте, VladD2, Вы писали:

iZEN>>По последним новостям проекта Mono до сих пор не решены проблемы работы "компонентов" WinForms.
VD>Источкник новостей, плиз. Или так уж честно и говори "по слухам".
Да у них на сайте чёрным по белому написано. Не могут решить, какую версию библиотеки GTK использовать и
использовать ли её вообще для реализации WinForms. Месяц назад смотрел специально.


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

VD>С компонентным подходм в Моно проблем нет. Тот же компилятор Немерле использует компонентный подход для динамической подгрузки макросов.
Про языки будем отдельно говорить, так и Delphi/Kylix можно подцепить.
В теме рассматривается проблема: а так ли хорошо реализован КОП в Linux или не очень хорошо.
Пока все склоняются в сторону того, что КОП в Linux реализован иначе, не как в Windows, но в любом случае использование подхода КОП как в Windows тоже не возбраняется.
В Windows, например, очень трудно использовать подход UNIX просто из-за того, что пользователи (программисты и просто пользователи) зашорены идеологией виндовс и не способны мыслить иначе, чем кнопочками, диалогами и командой "Выполнить".

Здравствуйте, Kolhoz, Вы писали:

K> Ещё одна легкоузнаваемая по полёту птица, не врубившаяся в тему. Право слово, смешно-с.

Товарищ Колхозник, я понимаю что я еще молод и мало у меня опыта, и по сравнению с Вами, с гуру, мне не тягаться, а мне и не надо тягаться, всего то я хотел узнать про КОП в линукс мире, я начал изучать линукс, и даже что то под него писать, понимаете я щас под виндами работаю над очень большим проектом, и не могу себе представить проект такого уровня без КОП, мне стало жутко интересно, как же в линуксе писать такие проекты, я стал искать, нашел нечто похожее в XPCOM. Просто у меня возникает некое такое чувство, что под линуксом не так уж и хорошо с КОП, ибо мало больших проектов, и то все в основном с таким ужасным количеством багов. Но не в этом суть, просто меня тошнит от манеры вашего ведения беседы (которое и беседой не назвать). Примерно то же самое видел в linuxforum.ru. Отныне буду просто игнорировать ваши сообщения.

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

Здравствуйте, Kisloid, Вы писали:

K>Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ?

CORBA вроде как. Хотя, это только некая низкоуровневая "несущая". Но вполне себе компонентная.

Kolhoz wrote:
> C>1. Невозможность нормального "обратного" общения. Программы в пайпах не
> C>могут нормально передать информацию "выше" по цепочке.
> Не пайпом единым... Открываем кого либо через popen(), и общаемся в обе
> стороны.
А все равно. Нет нормального механизма передачи исключительных ситуаций.

> C>2. Или ограниченность простыми текстовыми данными, или необходмость
> C>парсить данные в каждой программе.
> Это ни фига не недостаток. Это огромнейшее преимущество!!!
Недостаток. Кроме простого текста есть:
1. XML
2. JSON
3. Да хотя бы ini-файлы
4. Файлы с многострочными значениями

> C>3. Плохая совместимость со структурированными данными.
> Чушь. Офигенная совместимость — можно хорошие и правильные S-выражения
> гонять, можно глупый попсовый XML, можно любые бинарные форматы — кому
> что в голову взбредёт.
Какие стандартные утилиты догадаются, что последовательность &#3241 (код
вымышлен) — это буква "а"? Правильно, никакие.

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

> C>4. С бинарными данными еще хуже.
> Да? tar -xf — бла-бла-бла | bzip2
А как там у нас grep будет работать, например?

Кстати еще минус — отсутствие методов работы с непотоковыми данными. То
есть "cat somefile | rar | mail ..." уже не сделать — так как
rar'у нужен произвольный доступ для создания solid-архивов.

Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
случае в юниксах эта задача не решается).

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

Мой любимый пример: как мне таблицу с графиками из Calc вставить в
AbiWord, а потом ее там же редактировать с помощью inplace-редактора?

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

Здравствуйте, Cyberax, Вы писали:

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

Не пайпом единым... Открываем кого либо через popen(), и общаемся в обе стороны.

C>2. Или ограниченность простыми текстовыми данными, или необходмость
C>парсить данные в каждой программе.

Это ни фига не недостаток. Это огромнейшее преимущество!!!

C>3. Плохая совместимость со структурированными данными.

Чушь. Офигенная совместимость — можно хорошие и правильные S-выражения гонять, можно глупый попсовый XML, можно любые бинарные форматы — кому что в голову взбредёт.

C>4. С бинарными данными еще хуже.

Да? tar -xf — бла-бла-бла | bzip2

Или того лучше, dvgrab — | mpeg2encode ...

C>И т.п.

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

Здравствуйте, Kolhoz, Вы писали:

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

Коллеги, настоятельная просьба не скатываться на выяснение отношений и на очередной виток священной войны Unix vs Windows. Если есть желание вывалять себя в грязи, то пожалуйста в Священные Войны.

Здравствуйте, eao197, Вы писали:

E>Давайте все-таки без экстремизма и максимализма. Битие определяет сознание. Если кому-то приходится лабать околоофисный софт под Windows, то тут хочешь не хочешь, а с установленными MS (и миллионами не технических пользователей) правилами приходится считаться. Все же главная цель программы -- это выполнение возложенных на нее обязанностей. Внутренняя архитектура покупателей не интересует.

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

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

E>Поэтому лучше не издеваться над теми, кто на подобной GUI-ёвой компонентности деньги зарабатывает, а рассказывать о том, что что-то можно делать совсем по другому. Чтобы не было дилетантских вопросов "Как же в Linux-е без OLE?".

Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, преимущественно под Windows, и ну ни разу не приходилось применять их, вендовый стиль мышления. К чему бы это?

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

Боюсь, мне у них учиться нечему... У нас ведь и так есть всё то же что и у них. Наигрались в прошлом и выкинули на помойку — а они, вендузятники, подобрали. И объектные компонентные модели были, и унифицированные рантаймы. Всякого добра хватало. Много лет назад отбраковали.

Здравствуйте, Cyberax, Вы писали:

>> Ни разу не проблема.
C>Как через один пайп передать два потока одновременно? Только named pipe'ами.

Именно. Передаём имена пайпов или сокетов через коммандную строку.

C>Как мне из JavaScript прочитать S-expr?

Я видел не менее десятка библиотек. Только для JS и прочих ресурсных кастратов лучше использовать нормализованные S-выражения.

Типа, вместо ((a b) c) писать a b () . . c () . .

C> Упс... А как там с разными
C>кодировками?

Замечательно там с кодировками.

>> И? Где трудности? Вставить в пайплайн xslt кто запретил?
C>А как мне из xslt вызвать файловые операции со сторонними файлами?

А если это нужно — то вместо xslt использовать guile+ssax или CDuce. Собственно, я гораздо чаще SSAX использую чем XSLT.

>> C>После часа мучений с tee и прочими гадостями — просто взял
>> C>ActivePython+MSXML и за 10 минут написал все что нужно.
>> И чем же это не unix way?
C>COM ведь используется.

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

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

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

C>Это я к тому, что Unix-pipes — это далеко не идеал.

Pipes — это только один из многих механизмов. Это не есть краеугольная соль unix way. Соль unix way в способе разграничения компонент и в наборе общих требований к способу обмена между компонентами. Фундаментальнейшее из них: между любыми двумя компонентами можно встравить третий, так что ни первый ни второй об этом не будут знать. Всё остальное — детали и частности.

C>И что? Тот же Word замечательно рулится через OLE2 из
C>Python/Perl/VisualBasic/Brainfuck (да!)/C#/Nemerle/....

Бледненько. Делать поддержку OLE для каждого очередного языка — не в радость.

>> Это и есть unix way. Много маленьких уединённых программок с CLI,
>> способных общаться через пайпы И СОКЕТЫ.
C>Вот только этот мирок разбивается, когда встречается с суровыми
C>реальностями настоящих требований пользователей.

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

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

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

C>В частности, для данного примера хватило бы возможности реализовывать
C>свои потоки произвольного доступа. В OLE это УЖЕ есть — смотри IStream.

Чушь. Это НЕ решение.

>>> > ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной
>>> > силой.
>> C>Покажите мне fseek на named pipe или domain socket.
>> Зачем?
C>А вы думаете, что мир заканчивается однонаправленными потоками?

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

>> Зачем? Тем более shmem не масштабируется, так что фтопку.
C>Именно в этом и проблема с ним.

OLE, извините за выражение, тоже абсолютно не масштабируется. By design.

>> Какие факты? Есть две ущербные программульки, про unix way ничего не
>> знающие — так какое они имеют отношение тогда к обсуждаемой теме?
C>Есть 99% рынка домашних компьютеров, занятых этими ущербными программами.

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

C>А многочисленные попытки приспособить The Unix Way к десктопу — провалились.

Чушь. Лучшие десктопные приложения сделаны в рамках Unix Way. Например, лучший и удобнейший в своём классе GUI — у Wolfram Mathematica.

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

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

C>Технические спецификации — это НЕ документация к коду, это НЕ
C>документация к существующим системам, их НЕ нужно иметь в 10 форматах,
C>они ДОЛЖНЫ удобно редактироваться.

Ну так. Как раз для docbook задача.

Или по вашему "удобно редактироваться" — это в дебильном WYSIWYG, где ненужное (сами сказали) оформление будет постоянно отвлекать от сути? Ну так это и есть махровейший ламеризм. Хорошо, что мне никогда больше не придётся работать с такими, как вы, любителями бардака и бессистемности.

>> Ну ну. Не умеете вы этих кошек готовить.
C>Ага. А может это просто кто-то много о себе думает?

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

>> Тогда какие на хрен вордоофисы? Это задача для docbook.
C>Docbook не подходит по многим причинам:
C>1. Редактировать руками его неудобно.

А не надо руками.

C>2. Нет нормальных редакторов.

Есть. Emacs.

C>3. Куча ненужных возможностей.

В отличии от ворда, они не мешают.

C>4. Нет НУЖНЫХ возможностей.

xslt.

>> C>Плохие вордописцы. Или они там формулы рисуют?
>> Естественно рисуют.
C>Тогда действительно нафиг такое.

Вот вот. А что же это за документы, и без формул? Стихи Пушкина?

C>Ты просто не видел формул. Их и в 2D (на листе бумаги) неудобно иногда
C>рисовать, а уж в 1D — вообще невозможно.

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

>> C>ROTFL.
>> Это вы от незнания.
C>Задумайтесь, всякое общее утверждение — неверно.

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

>> C>Как раз GUI — это идеальный пример для "компонентов" в понимании
>> C>COM/.NET/Delphi.
>> Отвратительный пример.
C>А что делать? Мир — жестокая штука.

Да нет. Мир — глупая штука. Но он не мешает быть умным и не вестись за толпами идиотов.

>> Идеальный GUI — это, например, Tcl/Tk, с частичной генерацией кода на
>> стороне логики. Другой вариант — сервер, отображающий визуальные
>> компоненты, которые описываются в виде XML или S-выражений.
C>А кто описания строит? Если автомат — то в морг.

C>Ну а задавать расположение визульных компонентов вручную с помощью
C>layout'ов (которые можно описывать как угодно) — додумались уже давным
C>давно.

Вы абсолютно не в состоянии понять, о чём я говорю. Layout manager-ы тут вообще никаким боком.

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

Какие функциональщики? GUI — это такой КА. Вот и описывать его надо как КА.

C>Кстати, и откуда вы это знаете о моем опыте? Читали резюме? Видели мои
C>проекты? А?

Человек, считающий ООП идеальной моделью для GUI, опытным быть не может просто по определению.

Здравствуйте, eao197, Вы писали:

K>>А вот они почему-то не желают даже знать наших методов. Ленятся, что ли?

E>Из-за нашего высокомерного отношения.

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

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Мне кажется, что ты глубоко заблуждаешься .
АХ>Еще посмотрим, когда Mono доделают как он на Unix системах развернется .
Не доделают его — это нереально.
Он обречён на отставание.
Посмотри с какой скоростью плодятся всякие C# 3.0, LINQ, ADO.NET 3, WCF, WPF и прочие buzzwords.

Здравствуйте, McSeem2, Вы писали:

K>> Это RPC и к теме не относится. Тем более что у жабистов нет ничего сравнимого с другим, гораздо более правильным примитивным RPC — MPI. Так что уж как раз кластерами хвастаться — стыдно.

MS>Уважаемый товарищ Колхоз, в Ваших сообщениях присутствует рационалное зерно, но их общая тональность является совершенно неприемлемой. Лично у меня подобный тон вызывает негативные ассоциации, а именно, ассоциации с персонажем из песни группы "Х.Забей". "Я себя *удаком не считаю, я напротив конкретно продвинутый...". Поэтому, было бы конструктивно прикрутить фитилек, чтобы не коптил. При условии сохранения информативной составляющей сообщений.

Здравствуйте, EvilChild, Вы писали:

EC>Я компонентность Моно не обсуждал — читай внимательнее ту часть сообщения

Автор: EvilChild
Дата: 23.06.06

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

ну тогда твоё сообщение — просто оффтопик

Здравствуйте, Kolhoz, Вы писали:

K>Здравствуйте, eao197, Вы писали:

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

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

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

K>И тогда степень довария к этой информации будет довольно большой. Но естественно не 100%, к фактической информации такого довария не может быть никогда просто по определению. И, кстати, чем более важна для меня информация (то есть — если она используется в моих собственных рассуждениях), тем более низкий первоначальный коэффециент доверия она получит, и тем больше усилий по проверке её мне придётся приложить. Так что да, про количество звёзд я приму с высокой степенью доверия хотя бы от того, что мне абсолютно наплевать, сколько их там видно. Мне эта информация совершенно бесполезна.

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

Здравствуйте, VladD2, Вы писали:


VD>Так мелочь. Все продукты МС и продукты сделанные только под виндовс. Например 90% игрушек и систем атоматизации бизнеса доступны только под Виндовс. Попробуй найти ФарКрай или 1Эс под Линукс.

Сейчас уже все идет к тому что 90% игрушек будут недоступны под windows, а если ms затянет с вистой это очень быстро может стать реальностью.

Здравствуйте, Mamut, Вы писали:
M>Не, ну если этот весь процесс автоматизировать... Пишется shell-script, который вызывает связку R + MySQL + Python + latex + gnuplot + maxima ... Но это еще надо суметь автоматизировать...
Самое трудное — это автоматизировать процесс написания статьи.

Anton Batenev wrote:
> 200-300 тыс. файлов с средним объемом 1 MB — это куча мелких файлов?
> Реальный пример в моей практике — голосовая почта. В 1MB вмещается около
> 1 минуты сообщения (PCM, 8KHz, 16 bit, mono). Если нет, то вопрос снят,
> если да, то задержки на поиск файла и его трансфер через плату IP
> телефонии можно считать равными нулю.
Не тот пример. На единичных обращениях это неважно.

> P.S. возможно, что ФС под никсы могут делать каждое обращение на 1-5
> миллисекунды быстрее.
Вот именно это и важно. У меня при компиляции происходит обращение
примерно к 10000 файлов. Сэкономленная миллисекунда на каждом обращении
— это 10 секунд в сумме.

А так как инкрементальную компиляцию я запускаю раз 100 в день — то
общая сумма сэкономленного времени получается очень неплохой.

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

Здравствуйте, Sinclair, Вы писали:

S>Еще одно такое оскорбление в адрес неопределенного круга пользователей и ты пойдешь в бан.

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

Здравствуйте, VladD2, Вы писали:
VD>Короче, Колхоз в отпуске на месяц.
И уже давно. Напоминаю, что бан-лист можно не только писать, но и читать

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Mamut, Вы писали:

M>>

M>>ISDKSendPtr send;

M>>send -> SetTo(L"123 45 56");
M>>send -> SetCompany(L"My Company");
M>>send -> SetSubject(L"My Fax");
M>>send -> SetPrintFromApp(TRUE);

M>>/* Печатаем на принтер WinFax*/

M>>send -> Send();
M>>

M>>Красота! Считывание пришедших сообщений — в таком же стиле. Ну, COM'овском.

E>А чем это лучше, например, вот такого:
E>

E>system( "faxsend --to '123 45 56' --company 'My Company' --subject 'My Fax'" );
E>

Всем Ну, вернее, отсылка самого факса, конечно, практически равнозначна. А вот уже считывание факсовых событий, пробег по папкам в винфаксе и вытягивание из них сообщений может оказаться для Unix-way геморроем (пишу по памяти):

ISDKLogPtr log;
log.CreateInstance();

bstr_t folderID = log -> GetFolderFirst(FAX_FOLDER_STANDARD, L"");
if(folderID.Length() > 0)
{
    folderID = log -> GetFolderFirst(FAX_FOLDER_NONE, folderID);
    while(folderID.Length() > 0)
    {
        bstr_t messageID = log -> GetMessageFirst(folderID);
        while(messageID.Length() > 0)
        {
            bstr_t messageTo = log -> GetMessageTo(messageID);
            bstr_t messageCompany = log -> GetMessageCompany(messageID);
            bstr_t messageFax = log -> GetMessageFax(messageID);
            /* ... и так далее. Там штук 20 параметров, */
            /* включая даты, время, количество попыток, ошибки и т.д. */
            
            messageID = log -> GetMessageNext(folderID, messageID);
        }
        
        folderID = log -> getFolderNext();
    }
}

Unix-way подразумевает вызов faxsend для получения некоторого структурированного списка папок и сообщений. Этот список еще надо будет ручками распарсить и прийти, в общем, к такому же коду, что я привел, но с бОльшим геморроем (парсер-то придется писать).

Тут есть еще один грабель — пути к исполняемым фалам. В *nix же тоже есть переменная окружения PATH (это если я не ошибаюсь) То есть, faxsend на самом деле придется запускать как-то так:

/usr/local/faxsend/bin/faxsend --faxlist

А faxsend не обязательно в той папке находится В случае с COM'ом нам достаточно, чтобы WinFax был просто установлен в системе.

Но, опять же, я не против Unix-way. Он имеет право на существование и порой весьма и весьма полезен. Но он не единственный путь.

ЗЫ. WinFax'овые объекты тоже весьма Unix-way. Во-первых, возвращают только BSTR. Во вторых, функции GetMessageTime и GetMessageDate возвращают строки locale-aware. То есть, на US locale они возвращают, соответственно, "06/22/2006" и "08:01 РМ". А на RU locale — "22.06.2006" и "20:01"

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Здравствуйте, Kolhoz, Вы писали:


K>> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным!
АХ> Да все в точности наоборот!
АХ> Передайте от одного компонента другому имя файла и будет вам полнейший Unix way.

Какого файла? А если я туда netcat вставил? Или ssh?

АХ> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).

Нет.

Дао Unix way:
— на каждую функциональную единицу — отдельный компонент
— к компоненту предъявляются требования:
* возможность как программного так и интерактивного задействования всех его функций.
* корректное сообщение о любых исключительных ситуациях
* наличие максимально простого для программной обработки протокола передачи как потребляемых, так и производимых компонентом данных.
— в системе из нескольких компонент между любыми двумя компонентами должна быть возможность встроить третий

Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао.

АХ> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.

Что же? Объектно-ориентированную религию не предлагать, тошно-с.

Здравствуйте, Mamut, Вы писали:

M>Unix-way подразумевает вызов faxsend для получения некоторого структурированного списка папок и сообщений. Этот список еще надо будет ручками распарсить и прийти, в общем, к такому же коду, что я привел, но с бОльшим геморроем (парсер-то придется писать).

Вот насчет распарсить ручками -- это еще вопрос
Если бы faxsend был восстребованн именно в виде автономного приложения, то для парсинга его результатов уже давно были бы готовые библиотеки (вроде C++ оберток над PCRE или zlib). Возможно, даже созданные с помощью yacc/lex или antlr.

M>Тут есть еще один грабель — пути к исполняемым фалам. В *nix же тоже есть переменная окружения PATH (это если я не ошибаюсь) То есть, faxsend на самом деле придется запускать как-то так:
M>

M>/usr/local/faxsend/bin/faxsend --faxlist
M>

Вот это спорное утверждение, имхо (на счет полного пути к faxsend).

M>А faxsend не обязательно в той папке находится В случае с COM'ом нам достаточно, чтобы WinFax был просто установлен в системе.

"Просто установлен"
Помнится довелось с HTTP работать через WinInet. Так приложение сильно зависело от того, какая версия IE была на машине установлена.

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

---

На самом деле интересен подход в стиле Unix way в TIB/Rendezvous. Там демоны-router-ы работают как отдельные приложения на каждой из машин. А локальные приложения, нуждающие в TIB/Rendezvous, подключаются к локальному демону. Причем протокол там собственный, двоичный, но, тем не менее, явное разделение на компоненты, отвечающие только за одну задачу. А общение между компонентами происходит посредством библиотеки, поддерживающей протокол общения с локальным демоном. Поскольку общение с демоном идет через TCP/IP, то вместо локального демона можно легко подключится к удаленному (например, на ноутбуке пользователя может не быть локального демона, зато на его рабочей станции -- будет).

Так что Unix way можно рассматривать как стремление разнести разные задачи по разным процессам и избежать работы через общее адресное пространство и RPC механизмы. Поскольку такой подход дает надежность, масштабируемость и расширямость. Но ценой некоторых издержек. В том числе и по объему первоначального кодирования.

Просто примеры удобнее всего приводить с использованием стандартных утилит вроде tar, bzip, find, xarg, grep. Их использование в сочетании с конвейерами является наглядной, но далеко не полной иллюстрацией Unix way.

Но лично я не пытаюсь доказать, что Unix way лучше, чем COM или какая-то другая компонентная модель. Только хочу показать, что, имхо, компонентные технологии стремяться к монолитным приложениям, в которых компоненты взаимодействуют через вызовы процедур (будь то локальный вызов, или обращение к удаленному объекту посредством RPC). В то время как Unix way явно рекомендует вместо монолитных приложений создавать раздробленные на небольшие части приложения и организовывать взаимодействие между ними через другие формы IPC (а RPC следует избегать). Но без фанатизма.

Здравствуйте, Kolhoz, Вы писали:
K> GUI вторично всегда, даже в самом юзер-ориентированном проекте.
Фантастически упорное заблуждение.

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

Ок, рассмотрим твое утверждение чуть более подробно. Попробуем несколько отдалиться от интимных подробностей реализации и спросим себя, зачем вообще разработчики пишут программы. Тех, кто пишет их для себя, мы из рассмотрения исключим. Вместе с коллекционерами бабочек и стрелками из лука: мы рассуждаем о коммерческом программировании, а не о хобби.
Так вот, разработчики пишут для того, чтобы increase shareholder value. Как они это делают? Правильно, путем satisifying customer requirements.
Это основа любой коммерческой деятельности: ваши потребители — это ваше всё. То, что не влечет satisifying customer requirements, не приводит к increase shareholder value, а это уже нарушение due diligence и в некоторых странах подлежит преследованию по закону.

С этой точки зрения, рулят именно customer requirements. Эти требования всегда выражаются исключительно в виде наблюдаемого поведения продукта. Если это интерактивное приложение — то все, 90% требований будут выражены в терминах UI. Иногда на первый план выходят функциональные требования (как ICQ выплыла благодаря location-independent UIN, а не супергую), но это относительно редкие случаи. Почему Google Map рулит, а MapPoint сосет? Правильно, GoogleMap удобнее. Почему Gmail рулит, а Yahoo! Mail сосет? Првильно, потому что Gmail удобнее. И их внутренний дизайн не имеет к этому никакого отношения.

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

Бывают и неинтерактивные программные продукты. Запросто. Но их дизайн точно так же определяется архитектурой, которая обосновывается исходя из наблюдаемого поведения. Просто это поведение формулируется не в терминах GUI, а в терминах чего-то еще: спецификации API, ABI, или чего там еще.

Здравствуйте, Cyberax, Вы писали:

C>Вот был бы достаточно стандартный и распространенный бинарный объектный
C>RPC-протокол. Так ведь нету

И не надо такого счастья. Т.к. RPC — это зло. А COM-РПЦ — это двойное зло, неисцельная болезнь, некуоротимый зверь.
У нас расчетный сервер вначале работал через комовский RPC+shared mem. Это был сплошной и жестокий гемморой.
Во первых на сервере приходилось делать дополнительный поток который отслеживал не сдох ли клиент чтобы гасить сервер.
Во вторых танцы с бубном вокруг регистрации комовских компонентов. Какой сервер последний зарегестрировался в реестре тот и запустится — геморой с дебагжной и релизной сборкой.
В третих программирвать крайне неудобно, т.к. вся "крастота" РПЦ-вызовов сводилась на нет обилием костылей без которых никак не обойтись.

В итоге СОМ/RPC отправился в топку, были заюзаны два пайпа и наступила благодать .

Здравствуйте, Андрей Хропов, Вы писали:

АХ>>> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).
АХ>>> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.
E>>Что?
АХ>Ну нормальные компонентные модели вроде COM, CORBA, Java EE, .NET, которые поддерживают сообщения, обмен типизированными данными и т.п.

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

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

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

Не совсем так. Unix way (во всяком случае, в контексте этой дискуссии, как я её понимаю) не так мёртво завязан на синхронность вызовов. Что COM, что CORBA — одна и та же песня: синхронный вызов с непредсказуемой длительностью, с помощью которых ещё и эмулировать messaging приходится.

Смотри, в чём разница:

RPC (COM, CORBA... главное — procedure call)

A -- call func(...) --> B
  <-- return result --
Возвращается результат вызова функции.    
    
В случае долгоиграющей операции на B появляется
ещё один вызов:

A -- get_result(..) --> B
<-- return of get_result() --

Чистый messaging вдвое экономичней:

A -- msg_to_call_func --> B

тишина...

  <-- msg_with_result --

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

Опять таки, любой вызов DCOM/CORBA может завершиться исключением, а это уже требует в обязательном порядке обкладывать их обработкой исключений, с messaging всё проще — мы сразу честно признаёмся себе, что длительность вызова предсказать нельзя и ориентируемся на модель: "ждём сообщение", а не "должно сработать!".

Эмулировать RPC с помощью messaging — запросто (он и так на нём построен ), обратное — уже не так легко (минимум два варианта: polling или callback), плюс обязательная дополнительная загрузка канала связи. В случае callback (для CORBA) ещё нужно вставлять в клиенскую часть сугубо серверные приблуды итэдэ итэпэ. А простой messaging по IP: сокеты плюс простенькая сериализация. Да и то, в случае C можно структуры данных почти без изменений гонять (диспетчеризация только нужна и решение конфликта endian-ов).

Одним словом, messaging — базовый механизм, на нём уже можно сделать всё.

То же самое касается компонентных механизмов. Компоненты без инфраструктуры — нуль без палочки. В случае unix way требования к инфраструктуре упрощаются донельзя: текстовые данные, messaging по каналам связи — и всё. Инфраструктура тут — сам Unix. В случае всяческих CORBA/COM — толстенная управляющая прослойка, которая опять таки лежит поверх базовой инфраструктуры ОС.

АХ>Вот, скажем как вы подсистемы игры будете писать с помощью Unix way?

Играючи. Смотря какая игра, на самом деле.

Здравствуйте, Kolhoz, Вы писали:

K> Обе эти убогонькие программульки никакого отношения к unix way не имеют. А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в одну систему, и, как показывает практика, вендовозные ламеры, любители поредактировать табличку в текстовом процессоре, по эффективности работы просто рядом не валялись с теми кто пользуется подобной связкой. Пара дней — и идеального полиграфического качества статья готова, с идеальными графиками и достоверно проверенным качеством вывода и рассчётов. Вордописцы будут с тем же самым возиться не меньше месяца, как, опять же, демонстрирует та же самая практика.

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

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

Тем не менее, разговор свелся к обсуждению интеграции различных GUI приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и server side так же.

C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее
C>эффективно решать большую часть административных задач. Только
C>вот пора бы уже что-то новое придумать.

Есть мнение, что надо руководствоваться не религиозным чувством, а прагматизмом.
Если проще через пайпы — то через пайты. Если пайпы не катят — то пожалуйста: CORBA, DCOP и
черти-что еще. Примеры — KDE, KParts.

Здравствуйте, Mamut, Вы писали:

M>

M>ISDKSendPtr send;

M>send -> SetTo(L"123 45 56");
M>send -> SetCompany(L"My Company");
M>send -> SetSubject(L"My Fax");
M>send -> SetPrintFromApp(TRUE);

M>/* Печатаем на принтер WinFax*/

M>send -> Send();
M>

M>Красота! Считывание пришедших сообщений — в таком же стиле. Ну, COM'овском.

А чем это лучше, например, вот такого:

system( "faxsend --to '123 45 56' --company 'My Company' --subject 'My Fax'" );

?

Здравствуйте, Kolhoz, Вы писали:


K> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным!
Да все в точности наоборот!
Передайте от одного компонента другому имя файла и будет вам полнейший Unix way.
Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).
Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.

Здравствуйте, iZEN, Вы писали:

VD>>С компонентным подходм в Моно проблем нет. Тот же компилятор Немерле использует компонентный подход для динамической подгрузки макросов.
ZEN>Про языки будем отдельно говорить, так и Delphi/Kylix можно подцепить.
ZEN>В теме рассматривается проблема: а так ли хорошо реализован КОП в Linux или не очень хорошо.
ZEN>Пока все склоняются в сторону того, что КОП в Linux реализован иначе, не как в Windows,
Вообще в Unix-подобных системах. да.
Такой дизайн, изначально более продуманный чем в Windows.

ZEN> но в любом случае использование подхода КОП как в Windows тоже не возбраняется.
да.

ZEN>В Windows, например, очень трудно использовать подход UNIX просто из-за того, что пользователи (программисты и просто пользователи) зашорены идеологией виндовс и не способны мыслить иначе, чем кнопочками, диалогами и командой "Выполнить".
Да неправда ваша. Множество изначально Unix программ (Perl,Python,TeX,GCC,да и тот же Cygwin...) портировано на Windows и спокойно там шуршат. Кому надо — те пользуются.

Другое дело, я действительно люблю когда все работает out of the box.
Нажал кнопку "Установить" — все установилось , "выполнить" — выпонилось
и не люблю по запутанным мануалам изучать значения флагов в командной строке.
Пусть простые задачи будут простыми.

Здравствуйте, Kolhoz, Вы писали:

K> Вы, товарищ, не влезайте в тему которой не понимаете. Я про агентные протоколы говорю. А вы опять со своими примитивными RPC.

[. . .]

K> Это RPC и к теме не относится. Тем более что у жабистов нет ничего сравнимого с другим, гораздо более правильным примитивным RPC — MPI. Так что уж как раз кластерами хвастаться — стыдно.

Уважаемый товарищ Колхоз, в Ваших сообщениях присутствует рационалное зерно, но их общая тональность является совершенно неприемлемой. Лично у меня подобный тон вызывает негативные ассоциации, а именно, ассоциации с персонажем из песни группы "Х.Забей". "Я себя *удаком не считаю, я напротив конкретно продвинутый...". Поэтому, было бы конструктивно прикрутить фитилек, чтобы не коптил. При условии сохранения информативной составляющей сообщений.

Здравствуйте, eao197, Вы писали:

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

А я на веру ничего принимать не буду. Я попрошу библиографические ссылки, и постараюсь убедиться, что число получено из нескольких независимых источников. И тогда степень довария к этой информации будет довольно большой. Но естественно не 100%, к фактической информации такого довария не может быть никогда просто по определению. И, кстати, чем более важна для меня информация (то есть — если она используется в моих собственных рассуждениях), тем более низкий первоначальный коэффециент доверия она получит, и тем больше усилий по проверке её мне придётся приложить. Так что да, про количество звёзд я приму с высокой степенью доверия хотя бы от того, что мне абсолютно наплевать, сколько их там видно. Мне эта информация совершенно бесполезна.

Вот если мне приведут логическую конструкцию, которую я могу независимо проверить, не зависящую от достоверности каких либо внешних фактов — тогда да, тогда я буду на 100% уверен в корректности утверждения. В случае с 2+2=4 это возможно, в случае с количеством звёзд — нет.

E> Хотя бы потому, что я могу сослаться на этого профессора.

Как сослаться? На трёп ссылаться нельзя. Ссылаться можно на опубликованный результат, прошедший через peer review.

E> Или же описание механизма исключений в C++ я предпочту прочитать в книге Страуструпа, а не в "Освой C++ самостоятельно за 21 день".

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

VladD2 wrote:
> _>Хм. Те кто работает со спец.железками не совсем в себе?
> Та же виндовс разбирается на части без перекомпиляции. Даже есть
> специальный соят для формирования специализированных встраеваемых
> версий. Так что если в Линуксе это не делается, то это его личные
> проблемы, а не идеологические.
Это просто ты со встраиваемыми устройствами не работал. В дистрибутиве
WinCE просто содержаться объектные файлы, скомпилированные для всех
поддерживаемых архитектур. Из них собирается готовый образ с нужной
функциональностью.

Точно так же можно делать и в Линуксе — но зачем заниматься сексом, если
есть исходники и проще их скомпилировать под целевую платформу?
Кстати, и отладка на уровне исходников тогда возможна.

Причем для этого MS пришлось полностью переписать все — у WinCE
полностью свое ядро, не имеющее ничего общего с NT.

> К сведению, к Виндовс отосятся кроме ХРюши еще Мобаил- и ЦЕ-версии
> которые работают на куче разнообразных железок.
И которые не имеют ничего общего с NT.

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

В OS X используют медленный Mach, а NT имеет "псевдомикроядерную"
архитектуру — часть Win32API работает в отдельном сервере. Но если этот
сервер падает — то падает и вся система (в Win2K при этом выдается
красивое окошко с обратным отсчетом).

Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET. Знаю под линуксом есть мозилловская разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает до COM по качеству, скорости. Может я чего то упустил ?

Здравствуйте, Kisloid, Вы писали:

K>Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET. Знаю под линуксом есть мозилловская разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает до COM по качеству, скорости. Может я чего то упустил ?

Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП.

Здравствуйте, VladD2, Вы писали:

VD>Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП.
По последним новостям проекта Mono до сих пор не решены проблемы работы "компонентов" WinForms.

Здравствуйте, DJ KARIES, Вы писали:

DK>Если "В Linux компонентно всё" и "компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают", то почему я не наблюдаю XWindows под ОС Windows или MSDOS?
DK>Дядя Билл запретил?

Может просто плохо смотришь? http://www.interix.com/InteropToolworks.htm, http://x.cygwin.com/

Kolhoz wrote:
> C>А все равно. Нет нормального механизма передачи исключительных ситуаций.
> Как нет? Оно обычно в протокол зашито. Ни разу с этим трудностей не
> испытывал.
Проблема если нужно одновременно два разных потока данных как-то передавать.

> C>Недостаток. Кроме простого текста есть:
> C>1. XML
> Это — простой текст. Только очень дерьмовый простой текст. У меня всегда
> практически для обмена структурированной информацией S-выражения
> используются.
S-выражения — те же яйца, вид в профиль.

Как-то надо было сделать простую вещь — взять XML, пробежаться по всем
узлам с заданым путем, взять у них атрибут, сделать операцию с этим
атрибутом (это было имя файла, надо было regexp'ом его переименовать), а
потом записать его же в этот документ, но по другому пути.

После часа мучений с tee и прочими гадостями — просто взял
ActivePython+MSXML и за 10 минут написал все что нужно.

> C>2. JSON
> C>3. Да хотя бы ini-файлы
> C>4. Файлы с многострочными значениями
> И? Где тут проблемы, а?
Неудобно использовать стандартные утиллиты.

> C>Какие стандартные утилиты догадаются, что последовательность &#3241 (код
> C>вымышлен) — это буква "а"? Правильно, никакие.
> Unix-way не завязан на "стандартные" утилиты. Никак.
Без стандартных утиллит — получается простая идеология использования
соединенных фильтров.

>> > C>4. С бинарными данными еще хуже.
>> > Да? tar -xf — бла-бла-бла | bzip2
> C>А как там у нас grep будет работать, например?
> А зачем для бинарных данных grep?
А что, бинарные данные надо распечатывать и на стенки вместо обоев вешать?

> Ну так убогий rar — не unix way, он просто не вписывается. Любая
> компонентная система требует от компонентов следования определённой
> идеологии (и хорошо если идеологии, а не фиксированному API).
Нет. Это убогий unix way — так как RAR поддерживает создание архивов с
кодами коррекции ошибок (если повреждается часть файла — ее можно
восстановить). Но для этого ему нужен произвольный доступ к источнику и
результату.

> C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
> C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
> C>случае в юниксах эта задача не решается).
> ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной
> силой.
Покажите мне fseek на named pipe или domain socket.

Можно использовать shmem с некоторыми ограничениями, но все равно не
хватает возможности полноценно реализовать свой файл.

> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
> C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
> Обе эти убогонькие программульки никакого отношения к unix way не имеют.
Ага, конечно. "Факты не совпадают с теорией — тем хуже для фактов".

> А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в
> одну систему, и, как показывает практика, вендовозные ламеры, любители
> поредактировать табличку в текстовом процессоре, по эффективности работы
> просто рядом не валялись с теми кто пользуется подобной связкой.
Пробовал. ОЧЕНЬ неудобно писать спеки — если в Word/OpenOffice/... я
могу запустить редактор, нарисовать нужную диаграмму, cut&paste'ом
вставить в документ (не волнуюясь при этом об именах файлов), то с TeXом
один ужас получается.

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

> Пара дней — и идеального полиграфического качества статья готова, с
> идеальными графиками и достоверно проверенным качеством вывода и
> рассчётов.
Понимаете, мне НАФИГ НЕ НУЖНЫ документы полиграфического
качества, так работа идет с электронными копиями (а печатаются они для
отчетности).

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

Хотя в TeXе очень неудобно писать химические формулы (точнее, их вообще
неудобно как-либо в текстовом виде записывать).

> C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее
> C>эффективно решать *большую часть* административных задач. Только
> C>вот пора бы уже что-то новое придумать.
> Те же самые пайпы ИДЕАЛЬНО решают задачу построения любого, сколь угодно
> сложного GUI.
ROTFL.

Как раз GUI — это идеальный пример для "компонентов" в понимании
COM/.NET/Delphi.

> И все эти "объектно-ориентированные" решения из просто
> рядом не валялись с простым и элегантным решением в стиле unix way.
Вы LOR читаете? Очень фанатичный стиль похож...

Kolhoz wrote:

> C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в
> C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
> Обе эти убогонькие программульки никакого отношения к unix way не имеют.
> А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в
> одну систему, и, как показывает практика, вендовозные ламеры, любители
> поредактировать табличку в текстовом процессоре, по эффективности работы
> просто рядом не валялись с теми кто пользуется подобной связкой. Пара
> дней — и идеального полиграфического качества статья готова, с
> идеальными графиками и достоверно проверенным качеством вывода и
> рассчётов. Вордописцы будут с тем же самым возиться не меньше месяца,
> как, опять же, демонстрирует та же самая практика.
Вот именно что _ламеры_. А дай ламеру твой unix way, он и за год не справится. А не ламеры и в ворде шустро шуруют.

Попробуй потратить 2 недели обучая свою бабушку/маму word+excel для создания документа с парой графиков и mysql+tex на
те же 2 недели. О результатах расскажи.

Конечно, можно сказать, что ламерам за компьютер садиться нельзя, это и будет unix way, а windows way — компьютер вещь
простая, доступная всем, на чём MS деньги и зарабатывает.

Здравствуйте, Андрей Хропов, Вы писали:

iZEN>>А кто сказал, что COM и .Net — компонентные технологии?
АХ> COM = Component Object Model.
Маркетинг. Чтобы покупали виндовс.

iZEN>>Они обе завязаны на реестр и Windows.
АХ>COM да, .NET — в принципе нет (реализация от MS — да).
АХ>Но при чем здесь компонентность?
Компонентность подразумевает компонентность. Хотя да, здесь я с модульностью попутал.

iZEN>> Даже в Mono сталкиваются с неожиданными трудностями по реализации точка-нет,
АХ>Извините, .NET — это международный стандарт, который с Windows никак не связан.

Шарашка под названием ECMA, которую спонсируют Intel, Apple и Microsoft, не такая уж и иеждународная организация по стандартизации.
Вот когда туда войдут IBM и Sun, тогда можно будет говорить об отраслевых стандартах, но не более.
ISO — вот это организация, причём международная, независимая от частных фирм и инвесторов. CLR ещё не входит в планы стандартизации на уровне ISO.

АХ>В Mono сталкиваются с трудностями в основном при реализации поведения WinForms точно как в Windows, но это уже немного другое.
Выходит, что точка-нет несовсем компонентна, если нельзя просто взять и переписать нужный компонент (библиотеку) без затрагивания остальной части (системного, низкоуровневого) кода.

iZEN>> не говоря уже о реализации COM на не-MS-платформах. Эти т.н. "компонентные технологии" не являются таковыми, так как компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают.
АХ>А что компонентность обязательно включает в себя платформонезависимость?
АХ>Я здесь этого не нашел.

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

iZEN>>Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.
АХ>Это было во времена Win9x.
АХ>В 2000/XP/Server 2003 все гораздо лучше. Я не помню когда у меня последний раз был BSOD не по причине железа, вышедшего из строя.
Есть два узких места в линейке Windows NT, которые могут привести к BSOD или зависанию: некорректные драйверы видеокарты и драйвер печати. Часть кода работает в режиме ядра, хотя по всем канонам весь их код должен работать в режиме пользователя. Другой пример из моей практики: USB-устройство, втыкаемое пользователем, может повесить наглухо операционку, драйверы USB родные-виндовые. Это спорные моменты, конечно же, так как всё-таки приведённые примеры "работают" на уровне драйверов, что к пользовательским процессам вроде бы не относится.

Ладно, берём вирус msblast, который выбивает сервис RPC с пользовательского уровня!!!
Такое однозначно не пройдёт в *.NIX.

Здравствуйте, Cyberax, Вы писали:

>> Во! Начинаете понимать!
C>И? Это означает, что если что-то не делать, чтобы оно работало совместно
C>- то оно совместно работать не будет.

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

C>OLE на интерфейс вааще пофиг. Он работает с прямоугольниками рисования и
C>объектами данных. Как их интерпретирует приложение — личное дело самого
C>приложения.

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

Здравствуйте, Kisloid, Вы писали:

K>Здравствуйте, McSeem2, Вы писали:

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

K>Ну не скажи, вспомни хотя бы Win95 и сравни с XP, как небо и земля. Win 95 а может даже и Win 3.x дало верное направление развития, дало начало.

Win2K гораздо устойчивее чем WinXP. Вообще помоему WinXP по устойчивости только чуть лучше чем Win98SE.

Здравствуйте, Cyberax, Вы писали:

>> Узость мышления. Переключитесь на другую парадигму — и наоборот,
>> распределённые системы, построенные на обмене сообщениями будут для вас
>> гораздо проще императивных однопоточных последовательных систем.
C>Я уже давно понял, что делать распределенные или многопоточные системы
C>на чем-то кроме отсылки сообщений — это обычно гиблое дело.

+1

Только понимать тут нечего — это тривиально доказуется формально.

C>В случае с многопоточностью — постоянные проблемы с нужными
C>блокировками, а с распределенными системами — проблемы с реакциями на
C>сбои. Хотя, конечно, бывают случаи когда обычный RPC намного удобнее.

RPC — это транспортный уровень.

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

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

Здравствуйте, Kisloid, Вы писали:

K>Товарищ Колхозник, я понимаю что я еще молод и мало у меня опыта, и по сравнению с Вами, с гуру, мне не тягаться, а мне и не надо тягаться, всего то я хотел узнать про КОП в линукс мире, я начал изучать линукс, и даже что то под него писать, понимаете я щас под виндами работаю над очень большим проектом, и не могу себе представить проект такого уровня без КОП, мне стало жутко интересно, как же в линуксе писать такие проекты, я стал искать, нашел нечто похожее в XPCOM.

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

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

Чушь говоришь. Подавляющее большинство больших проектов делается в рамках unix way. Я не видел success stories по настоящему крупных систем на DCOM.

K> Но не в этом суть, просто меня тошнит от манеры вашего ведения беседы (которое и беседой не назвать). Примерно то же самое видел в linuxforum.ru. Отныне буду просто игнорировать ваши сообщения.

Ты научись сначала понимать, что люди говорят. Ты же русским языком не владеешь! И эта конкретная ветка — тому пример. Я про одно — а ты и подпевалы — совсем про другое. Даже умудрился где-то углядеть якобы "презрение к пользователям Windows".

Вот например — с какого перепуга ты меня в пользователи linux записал, а?!? Кто тебе дал такое право? Я хоть словом об этом обмолвился? Наоборот, я постоянно настаиваю на применении концепций unix way под windows. Но ты ж читать не умеешь, куда тебе до таких тонкостей опускаться.

Здравствуйте, Sinclair, Вы писали:

S>Почему Gmail рулит, а Yahoo! Mail сосет? Првильно, потому что Gmail удобнее.

Не самый удачный пример. Многие пользователи Yahoo! Mail забили на него после того, как POP3 доступ к Yahoo! Mail в 2001 или 2002-м сделали платным. Да и на момент появления Gmail с 1Gb почтовым ящиком, размер ящика на Yahoo! был какой-то совсем маленький (кажется 25Mb). А в 2001 Yahoo! Mail в связке с Yahoo! Chat была просто отличной службой. Так что Yahoo! Mail урыл его же собственный маркетинг.

Здравствуйте, Cyberax, Вы писали:

C>А Reiser4FS на Винде есть? Или любая другая нормальная FS, которая не
C>торомзит?

А меня и NTFS устравивает. Зачем мне искать от добра дотбра?

Здравствуйте, kan_izh, Вы писали:

_>Хм. Те кто работает со спец.железками не совсем в себе?

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

>> _>Не укладывается в твою супер-концепцию? Кстати, неплохо бы вспомнить,
>> что винда по этому
>> _>пути "гибкости" пошла по необходимости, чтобы противостоять
>> конкуренции. Гибкость линуксов же — by design, с рождения.
>> По какому пути Виндва пошла? Ты вообще историю то хорошо знаешь?
_>Фактически по x86, а всякие alpha были так... А уж если сравнивать ситуацию несколько лет назад...

К сведению, к Виндовс отосятся кроме ХРюши еще Мобаил- и ЦЕ-версии которые работают на куче разнообразных железок.
Но это к делу не относится. Я говорил об истории. Дело в том, что архитектура NT была сформирована еще до того как появились первые сообщения о Линуксе. И формиловалась она под влиянием очень известного человека в мире миникомпьютеров. NT изначально была архитектурно более гибка чем Линукс. А линукс как раз послал к чертям все завоевания научной мысли тех лет и породил монолитную архитектуру смело шагнувшую на много лет назад.

_> попробуй винду
_>поставить и юзать на железку без монитора/клавы/и не дай бог мыши. Только недавно задумались о командной строке в винде.

Ага. Только недавно. Примерно в 1992-ом году. А в 2000-ном был вариант виндовс для встаеваемых систем вообще не имеющих GUI и управляемый исключительно из командной строки удаленно.

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

В общем, приплыли. Сервер на котором ты сейчас общашся работает под управлением Windows 2003 Server. У него нет ни клавиатуры, ни монитора, ни мыши и вообще к нему по два года никто физически не подходит. Управляется он через терминал-сервис причем многие лезут на сервер с другой стороны земного шара.

Терминалка у нас работает с момента появления этого сайта в 2002 году.

_>Да, согласен, несколько слукавил, выкинуть можно. Я больше имел в виду, что линух в этом отношении честнее — ни com ни
_>.net и ничего подобного нет "по умолчанию", ничего не навязывается.

Нет тут никакой честности. Правда в том, что в Линукс просто нет никаких компонентных технологий бай дефолт. Зато есть возможность пользоваться общеупотребимыми. Что в общем-то не хуже и не лучше чем в других ОС. И нечего тут разводить политические дрязги.

>> _>Вообще говоря, по отношению к сабжу, то, что его считают "правильным"
>> для винды.
>> Хм. Свежая мысль однако.
>> Кто считает? Я вот знаю КОМ очень неплохо, но так не считаю. Мне вот
>> компонентная модель Явы и дотнета нравится куда больше. Хотя как
>> средство межязыковой интеграции КОМ пока что никем не превзойден. Назови
>> хотя бы одну компонентную технологию которая поддерживалась бы в
>> стольких языках.
_>Pure C (dll/so)?

Это вообще не компонентные технологии.

_>А что, модель компиляции исходников в линухе и иже с ними — вполне таки компонентная модель. Простая как швабра, дуб
_>дубом (в смысле крепкая).

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

Кроме того компонетная технология подразумевает наличие инфраструктуры. Ведь просто загрузка модулей мало интересна. Важно наличие фрэймворка позволяющего эффективно разработывать софт с его помощь. Ведь в принципе КОМ без проблем можно реализовать с нуля на С++. Вот только это огромный объем работы время на который изымается из времени отведенного на основные проекты.

Здравствуйте, Cyberax, Вы писали:

>> Извини, но это руки.
C>Спорим?



C>Правая синтетика — инкрементальная перестройка проекта BJam'ом на
C>Линуксе работает в десять (десять!) раз быстрее. Как показал профилятор
C>- большая часть времени в Винде тратится на stat()'инг файлов.

Я не знаю что такое BJam и не знаю что такое stat(). Но я периодически обрабатываю большие объемы информции и знаю, что при грамотном подходе проблем в дисковой подсистеме нет.

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

Загрузка происходит с МБР, а что до безопасности то тебе вроде скорость нужна была. В общем, тебе явно нужна пенисометрия не имеющая ничего общего с жизнью. А по жизни НТФС всем хватат за глаза. Потому никого твоя пенисометрия не колшит. В Линуксе 99.9% тоже ставя то что идет по умолчанию и не выпендриваются.

И вообще зря я стобой снова спорить влез. Речь шала о доступных под ОС возможностях. Сменяемые файловые системы это баловство для очень посвященных. А вот наличие МС Сиквела, Фаркрая, Винкомандера, Студии с дотнетом... она совсем не заменяет.

VladD2 wrote:
>> > C>Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM.
>> > В чем смысл этого ответа?
> C>Чтобы сомнений в компетентности не возникало.
> Ты мои сообщения, то в этой ветке читал?
Нет, только пишу.

> C>Ничто. Ничего, кроме того, что ни одна распространенная тулза разработки
> C>для Windows на него не ориентирована.
> Это лож. Сред разработки для Явы под виндовс больше всего насвете.
Среды разработки для Java пишутся (обычно) на Java и работают из-за
этого везде.

> XPCOM просто самопальный клон КОМ-а который можно использовать в любом
> компиляторе С++ при наличии соотвествующих библиотек.
А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу
ATLевских, всякие аналоги ATL/MFC Trace Tool?

Здравствуйте, VladD2, Вы писали:

VD>К сведению, к Виндовс отосятся кроме ХРюши еще Мобаил- и ЦЕ-версии которые работают на куче разнообразных железок.
VD>Но это к делу не относится. Я говорил об истории. Дело в том, что архитектура NT была сформирована еще до того как появились первые сообщения о Линуксе. И формиловалась она под влиянием очень известного человека в мире миникомпьютеров. NT изначально была архитектурно более гибка чем Линукс. А линукс как раз послал к чертям все завоевания научной мысли тех лет и породил монолитную архитектуру смело шагнувшую на много лет назад.
Выделенное — чистый, незамутнённый бред.
Первое упоминание о Linux датировано августом 1991 года, когда Линус Торвальдс опубликовал своё первое сообщение о начале разработки UNIX-подобного ядра в эхоконференции, посвящённой "правильному" Minix.

Newsgroups: comp.os.minix
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: What would you like to see most in minix?
Date: 25 Aug 91 20:57:08 GMT

Привет всем, кто тут пользуется minix'ом

Я делаю (свободную) операционную систему (просто хобби, ничего такого большого и профессионального, как GNU) для 386(486) клонов AT. Я вожусь с ней с апреля, и она уже скоро будет готова. Мне бы хотелось услышать мнению людей о том, что им нравится/не нравится в minix'е, поскольку моя ОС кое в чём похожа на него (помимо всего прочего, у неё такое же физическое расположение файловой системы (по практическим причинам)).

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

Linus (torvalds@kruuna.helsinki.fi)

Источник: http://linux.yaroslavl.ru/docs/about/torvalds/torvalds.html

Тогда ещё NT в проекте не стояло. OS/2 разрабатывалась совместно с IBM. Инженеры VAX/VMS начали подтягиваться в Microsoft в 1989 году с развалом бизнеса операционок DEC. И первая публичная версия NT 3.1 состоялась 27 июля 1993 года. Что было с Linux в 1993 году говорить нужно?

VD>Ага. Только недавно. Примерно в 1992-ом году. А в 2000-ном был вариант виндовс для встаеваемых систем вообще не имеющих GUI и управляемый исключительно из командной строки удаленно.

Опять же, любопытный источник: http://firedrake.org/paddy/images/non-unix_os_history_0.3.2.pdf

>>> _>Вообще говоря, по отношению к сабжу, то, что его считают "правильным"
>>> для винды.
>>> Хм. Свежая мысль однако.
>>> Кто считает? Я вот знаю КОМ очень неплохо, но так не считаю. Мне вот
>>> компонентная модель Явы и дотнета нравится куда больше. Хотя как
>>> средство межязыковой интеграции КОМ пока что никем не превзойден. Назови
>>> хотя бы одну компонентную технологию которая поддерживалась бы в
>>> стольких языках.
_>>Pure C (dll/so)?

VD>Это вообще не компонентные технологии.

_>>А что, модель компиляции исходников в линухе и иже с ними — вполне таки компонентная модель. Простая как швабра, дуб
_>>дубом (в смысле крепкая).

VD>У тебя очень странные понятия о компонентых технологиях. Компоненты обязаны позволять стрить программу из поставляемых одтедьно модулей. При этом не должна требоваться компиляция или информация о модулях в текстовом виде.
Компоненты EJB имеет дескрипторы развёртывания в текстовом виде (в формате XML), но от этого EJB не перестали быть компонентами.

VD>Кроме того компонетная технология подразумевает наличие инфраструктуры. Ведь просто загрузка модулей мало интересна. Важно наличие фрэймворка позволяющего эффективно разработывать софт с его помощь. Ведь в принципе КОМ без проблем можно реализовать с нуля на С++. Вот только это огромный объем работы время на который изымается из времени отведенного на основные проекты.

Она есть и там и там.

VladD2 wrote:
> C>Можно пример таких сред? Я знаю, пожалуй, только OmniCore.
> VS, например.
А разве в ней есть поддержка Java? Я видел только J#.

> C>XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что
> C>кроме тулзов из Mozilla для XPCOM больше ничего почти и нет.
> Это к чему сказано?
> У меня орпределенно создается впечатление, что что ты разговариваешь не
> со мной, а с некими потусторонними силами. Если так будет продолжаться
> дальше, я буду вынужден просто игнорировать все твои сообщения.
Тебе вроде бы сказали, что формально в Винде можно использовать другие
компонентные архитектуры. Но реально используется практически только
один COM.

iZEN wrote:

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

Здравствуйте, Cyberax, Вы писали:

C>BJam внутри делает проверку, что файл можно открыть — это примерно
C>аналогично опции "/Q" (я как раз пытался ускорить BJam, заменяя открытие
C> файла на проверку ACLей).

Не аналогичен. Вот мой пример аналогичен. Проверка данты требует открытия файла.

/Q читает информацию о защите. Что в виндовс довольно медленная процедура.

C>Не веришь — смотри файл headers.c и hcache.c из исходников BJam.

Я тебе не верю. Зачем мне куда-то еще смотреть?

Здравствуйте, Streamer1, Вы писали:

S>тогда чем вы можете объяснить свои категорические заявления, без ознакомления о чем (тобишь о каких условиях) речь идет?

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

Здравствуйте, Cyberax, Вы писали:

C>Plutonia Experiment wrote:
>> Ты спутал НТФС с ФАТ32 В нем перебор делается быстрее чем поиск по имени.
>> Как раз по именам в НТФС ищется быстрее, нежели перебором
>> findfirst/findnext.
>> Все оттого, что поиск в дереве выполняется быстрее перебора всех элементов.
C>Ничего я не перепутал. Почитай лучше про алгоритм "танцующих деревьев" в
C>Reiser4.

при сканировании
include-файлов они ищутся по именам, что немного медленнее перечисления
findfirst/findnext'ом.

Узнаешь автора этих строк ? Так вот, это утверждение ложно для системы НТФС(и рейзер4) и истинно для фат32. Так понятнее ?



C>Мне просто лень было делать более точные замеры. Я уже как-то сюда писал
C>мини-бенчмарк: http://rsdn.ru/Forum/?mid=1710544

Автор: Cyberax
Дата: 02.03.06

Это не бенч. Это подгон под нужные результаты.

Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, VladD2, Вы писали:

VD>>К сведению, к Виндовс отосятся кроме ХРюши еще Мобаил- и ЦЕ-версии которые работают на куче разнообразных железок.
VD>>Но это к делу не относится. Я говорил об истории. Дело в том, что архитектура NT была сформирована еще до того как появились первые сообщения о Линуксе. И формиловалась она под влиянием очень известного человека в мире миникомпьютеров. NT изначально была архитектурно более гибка чем Линукс. А линукс как раз послал к чертям все завоевания научной мысли тех лет и породил монолитную архитектуру смело шагнувшую на много лет назад.
ZEN>Выделенное — чистый, незамутнённый бред.
ZEN>Первое упоминание о Linux датировано августом 1991 года,

а NT начали делать в 89ом.

Здравствуйте, Kolhoz, Вы писали:

K> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, преимущественно под Windows, и ну ни разу не приходилось применять их, вендовый стиль мышления. К чему бы это?

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

K> Боюсь, мне у них учиться нечему... У нас ведь и так есть всё то же что и у них. Наигрались в прошлом и выкинули на помойку — а они, вендузятники, подобрали. И объектные компонентные модели были, и унифицированные рантаймы. Всякого добра хватало. Много лет назад отбраковали.

Имхо, научится всегда есть чему, но это уже офтопик.

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

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

Автор: eao197
Дата: 19.06.06

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

Здравствуйте, Mamut, Вы писали:

M>Что-то новости старые. Qt уже давно в версии 4.2, и GPL под Windows, а где KDE?

Сдается мне, KDE for Windows выйдет вместе с KDE4 for Linux.

Здравствуйте, Anton Batenev, Вы писали:

K>> Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview.

AB>Т.е. это твоя разработка?

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

AB>1. Я хочу понять, чем эти два подхода так сильно отличаются (понять визуально [если не сложно, то скриншотики с подробными комментариями], поюзать, если возможно [URL для скачивания]).

Для mathview очень легко понять визуально разницу. Там DPS торчит из всех щелей.

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

Идите на http://library.wolfram.com/infocenter/MathSource

Там много очень маленьких и простых гуёвых примочек, сделанных поверх фреймворка mathview. Оцените, как легко и просто делаются такие сложные и красивые вещи.

AB>3. Все обдумать, взвесить, и, при удобном случае, попытаться попользовать.

Для попробовать — проще всего взять Tcl/Tk, и что либо простенькое нарисовать.

Здравствуйте, dmz, Вы писали:


dmz>Есть мнение, что надо руководствоваться не религиозным чувством, а прагматизмом.
dmz>Если проще через пайпы — то через пайты. Если пайпы не катят — то пожалуйста: CORBA, DCOP и
dmz>черти-что еще. Примеры — KDE, KParts.

+1
Хотя можно сделать так:

s/CORBA/Ice/g

Здравствуйте, Cyberax, Вы писали:

C>Иностранные поисковики на слова "agent protocol" выдают всякую фигню, а
C>родной ya.ru на "агентный/агентский протокол" выдает, в основном,
C>рефераты про искусственный интеллект.

C>Так что прошу примеры агентских протоколов и программ, их использующих.

http://en.wikipedia.org/wiki/Agent_based

И, да, это часто относят к искусственному интеллекту — но совершенно напрасно. Область применения агентной модели гораздо ширшее и глубжее.

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

C>Вообще-то у Явистов есть JMS (Java Message Service) и его адаптация для
C>high-performance computing.

C>MPI, кстати, тоже есть. Поищите по словам JavaMPI и mpiJava.

Есть то он есть. Только вот его как бы и нет — производительность оставляет желать всего хорошего, заходите почаще, а лучше мы к вам. Как я матерился, когда в последний момент пришлось всё на C++ переписывать, осознав, что Java не тянет.

Здравствуйте, Kolhoz, Вы писали:

K>>> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал,
K>>> преимущественно под Windows, и ну ни разу не приходилось применять их,
K>>> вендовый стиль мышления. К чему бы это?
C>>Ну так покажите эти GUI. И их пользователей. Какие проблемы?
AB>Я так понимаю, что образец GUI для подражания в количестве "много" нам не покажут?
K> Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview.

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

1. Я хочу понять, чем эти два подхода так сильно отличаются (понять визуально [если не сложно, то скриншотики с подробными комментариями], поюзать, если возможно [URL для скачивания]).
2. Хочу оценить сложность создания подобного одним человеком, который говорит, что этот гуй хорош.
3. Все обдумать, взвесить, и, при удобном случае, попытаться попользовать.

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

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

>> Ни разу не проблема.
C>Как через один пайп передать два потока одновременно? Только named pipe'ами.
А оно точно надо? В один поток — точно нельзя? Точно-точно?


>> И? Где трудности? Вставить в пайплайн xslt кто запретил?
C>А как мне из xslt вызвать файловые операции со сторонними файлами?

А это уже не поток. Работайте с файлами — но это уже другая история.
XML вообще формат, не рассчитанный на работу в потоковом стиле.
Вот хоть что делайте.


>> C>ActivePython+MSXML и за 10 минут написал все что нужно.
>> И чем же это не unix way?
C>COM ведь используется.
Я так понимаю, COM что бы MSXML дергать? Ну возьмите libxml которая есть в
питоне — и никакого кома.

C>Это я к тому, что Unix-pipes — это далеко не идеал.
Ничто — не идеал. Гвозди — молотком, шурупы — отверткой. Ы?

>> способных общаться через пайпы И СОКЕТЫ.
C>Вот только этот мирок разбивается, когда встречается с суровыми
C>реальностями настоящих требований пользователей.

Боюсь все эти суровые нереализуемые требования в реале сведутся к требованию
воткнуть эхельную таблицу в ворд и там ее редактировать. Что в реальной жизни и под
виндовс умеет крайне мало приложений — например, эхельная таблица в Лотус вставляется
как картинка. Даже в html или rtf-не конвертируется.

С другой стороны, внутри офисных пакетов — и OO и вроде KOffice так умеют.
С третьей стороны и телевизор (kmplayer) у меня вполне встраивается в бровзер.
KParts — и не говорите что не стандарт. В рамках KDE такой-же стандарт, как ActiveX
в Win.

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

>> Какие факты? Есть две ущербные программульки, про unix way ничего не
>> знающие — так какое они имеют отношение тогда к обсуждаемой теме?
C>Есть 99% рынка домашних компьютеров, занятых этими ущербными программами.

Я таки не понял, если рару нужно random access то почему бы ему просто не скормить
файл? Из какого-то принципа? И чем в данном случае его поведение отличается от его
поведения под win?

C>А многочисленные попытки приспособить The Unix Way к десктопу — провалились.
Была где-то ссылка на статью, где убедително доказывалось, что KDE — это Unix Way в полный рост.
Стало быть, не провалились.

На самом деле, Unix way это не что иное, как принцип K.I.S.S. И ничего более.

Здравствуйте, Cyberax, Вы писали:

C>С Mathematica так не получится (она OLE2 не поддерживает).

???

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

C>А вот с Visio — вполне. Данные к диаграмме (таблица какая-нибудь,
C>например) привязываются через OLE Linking, все это сохраняется в
C>документ. На компьютерах, где нет Visio будет использоваться сохраненное
C>WMF-описание встроенного объекта.

У Visio и задачи существенно попроще, можно и WMF-ом обойтись. А как что посложнее — вся OLEшечная инфраструктура в конкретном пролёте.

>> Да и сами посудите — много ли можно наавтоматизировать на Вижуал Васике?!?
C>Да сколько угодно:
C>1. VB — сам по себе вполне нормально подходит для автоматизации.

Нет. Не подходит. Тяжелый слишком.

C>2. Делается внешний компонент и подключается к Word'у через механизм
C>Addin'ов.

Такие трудности — и ради какой-то мелочи? Почему вы так любите создавать себе трудности и героически их преодолевать?

C>3. Управляем Word'ом полностью из внешней системы (через OLE2, на любом
C>языке, в том числе и на Haskell).

C>Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего
C>текущего проекта предлагаете на сервер вынести?

Именно так! Ещё раз посмотрите на Wolfram Mathematica и на то, как к ней приделываются произвольные способы отображения тех самых 3D-поверхностей (одна из примочек, которая через OpenGL, точно свободно доступна).

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

Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, Андрей Хропов, Вы писали:

iZEN>>>А кто сказал, что COM и .Net — компонентные технологии?
АХ>> COM = Component Object Model.
ZEN>Маркетинг. Чтобы покупали виндовс.
Так ты спрашиваешь кто сказал? Microsoft сказал назвав так технологию.

iZEN>>>Они обе завязаны на реестр и Windows.
АХ>>COM да, .NET — в принципе нет (реализация от MS — да).
АХ>>Но при чем здесь компонентность?
ZEN>Компонентность подразумевает компонентность. Хотя да, здесь я с модульностью попутал.
При чем здесь завязанность на реестр и компонентность или модульность?
ПО твоему что сборки .NET — не модули?

iZEN>>> Даже в Mono сталкиваются с неожиданными трудностями по реализации точка-нет,
АХ>>Извините, .NET — это международный стандарт, который с Windows никак не связан.

ZEN>Шарашка под названием ECMA, которую спонсируют Intel, Apple и Microsoft, не такая уж и иеждународная организация по стандартизации.
Ага, конечно . см. здесь.
Цитата:

ECMA was founded in 1961 to standardise computer systems in Europe.

В 1961 ни Intel, ни Apple, ни Microsoft, ни Sun не существовало. Только IBM был.

ZEN>Вот когда туда войдут IBM и Sun, тогда можно будет говорить об отраслевых стандартах, но не более.
Железная логика. То есть 3 ведущих компании — это не кворум, а 5 — уже кворум.
А как же без Sony, а без AMD?
В общем ерунду говоришь.


АХ>>В Mono сталкиваются с трудностями в основном при реализации поведения WinForms точно как в Windows, но это уже немного другое.
ZEN>Выходит, что точка-нет несовсем компонентна, если нельзя просто взять и переписать нужный компонент (библиотеку) без затрагивания остальной части (системного, низкоуровневого) кода.
Базовые сервисы, взаимодействующие с ОС, такие как GUI надо переписывать под конкретную ОС/GUI framework.
Сложность реализации уже зависит от ОС/GUI framework. Кто сказал что это будет просто?

iZEN>>> не говоря уже о реализации COM на не-MS-платформах. Эти т.н. "компонентные технологии" не являются таковыми, так как компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают.
АХ>>А что компонентность обязательно включает в себя платформонезависимость?
АХ>>Я здесь этого не нашел.

ZEN>Компонентность необязательно должна быть платформонезависимой и в точка-нэт это так.
Сам себе противоречишь (см. выделенное)


iZEN>>>Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.
АХ>>Это было во времена Win9x.
АХ>>В 2000/XP/Server 2003 все гораздо лучше. Я не помню когда у меня последний раз был BSOD не по причине железа, вышедшего из строя.
ZEN>Есть два узких места в линейке Windows NT, которые могут привести к BSOD или зависанию: некорректные драйверы видеокарты и драйвер печати. Часть кода работает в режиме ядра, хотя по всем канонам весь их код должен работать в режиме пользователя. Другой пример из моей практики: USB-устройство, втыкаемое пользователем, может повесить наглухо операционку, драйверы USB родные-виндовые. Это спорные моменты, конечно же, так как всё-таки приведённые примеры "работают" на уровне драйверов, что к пользовательским процессам вроде бы не относится.
Ха, а в Linux наверное драйвера не в режиме ядра работают?
здесьпишут:

Today Linux is a module-loading monolithic kernel. Device drivers and kernel extensions typically run in ring 0, with full access to the hardware

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

ZEN>Ладно, берём вирус msblast, который выбивает сервис RPC с пользовательского уровня!!!
ZEN>Такое однозначно не пройдёт в *.NIX.
А под Linux эксплойтов нет ?
Почитайте здесь. Ошибку то поправили, но не надо утверждать что в Linux все так хорошо. Просто эксплойты в Windows активнее ищут, поэтому и больше находят. А так багов и в Линуксе хватает.

Kolhoz wrote:
> K> Очень хорошим чистым и наглядным примером компонентно ориентированной
> технологии является на мой взгляд .NET.
> ?!?
Ага.

> В .NET из компонентностей есть только довольно примитивные формы RPC и
> сериализации и интерфейс ко всё тому же OLE. Ничего чистого и тем более
> наглядного не прослеживается — нет даже общей идеологии.
Назовите НЕпримитивные формы RPC.

Ну и OLE к .NET не имеет никакого отношения. Может не стоит показывать
своего незнания в обоих предметах?

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

> Вы поработайте для сравнения в команде, где весь документооборот на вордах,
> и в команде, где с одной стороны docbook, а с другой —
> bugzilla+cvszilla. Поймёте, почему вторая команда будет свысока смотреть
> на первую.
Пробовал. После $#TY$OIU# с docbook в итоге перешли на Word.

И уж системы багтрекинга и SCM к формату документов не имеют никакого
отношения.

> Ламер — не тот, кто пользуется виндовсом (я вот почти только под виндовс
> и писал всегда), а тот, кто не желает думать своей головой и ведётся на
> дешевый appeal to authority.
Ага. Всякой чепухе про Unix way, например.

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

>> C>Нет, правило хорошее. Если что-то можно не распределять — то лучше не
>> C>распределять.
>> Как раз у меня есть противоположный собственный опыт. То, что казалось
>> бы, может работать монолитом, выигрывает по некоторым параметрам
>> (надежность, масштабируемость) будучи распределенным.
C>Сравни сложность разработки — распределенные приложения заметно сложнее
C>отлаживать и писать.

А как же Эрланг?

iZEN wrote:
> FUSE <http://fuse.sourceforge.net/&gt; (Filesystem in USErspace) была
> частью проекта AFVS.
Не надо мне это 10 раз повторять — я прекрасно знаю что такое FUSE.

> C>И если я хочу написать портируемую программу — то могу рассчитывать
> C>только на пайпы/сокеты и временные файлы.
> FUSE <http://fuse.sourceforge.net/&gt; работает на:
> http://fuse.sourceforge.net/wiki/index.php/OperatingSystems (Linux и
> FreeBSD)
> Учитывая, что исходный код открыт, можно надеяться, что будет портирован
> на более экзотические OS.
Например, мне важны: Solaris, HP-UX, Cygwin, FreeBSD старых версий, QNX,
Windows.

На многих из них FUSE не будет очень долго. Кроме того, FUSE не входит в
LSB (и соответствующий ISO-стандарт).

> (Пример из 100 строк на Си для драйвера "Hello World" разве не впечатляет?)
Посмотрите Plan 9

Plutonia Experiment wrote:
> C>Вот *если* понадобится — тогда и запишется. Например, на 1Гб памяти
> C>с CompressedCache патчем компиляция ядра Линукса проходит без единого
> C>касания диска.
> А для чего это ? что бы на форум сюда прийти и сказать об этом ?
> Проекты, с которыми я работаю, создают временных файлов и всякой бряни
> от гигабайта и до трех. Не пойму, чем это режим мне лично поможет.
"А для чего это ? что бы на форум сюда прийти и сказать об этом ?" (c) ты.

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

Здравствуйте, iZEN, Вы писали:

ZEN>А кто сказал, что COM и .Net — компонентные технологии?
COM = Component Object Model.

ZEN>Они обе завязаны на реестр и Windows.
COM да, .NET — в принципе нет (реализация от MS — да).
Но при чем здесь компонентность?

ZEN> Даже в Mono сталкиваются с неожиданными трудностями по реализации точка-нет,
Извините, .NET — это международный стандарт, который с Windows никак не связан.
В Mono сталкиваются с трудностями в основном при реализации поведения WinForms точно как в Windows, но это уже немного другое.

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

ZEN>Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.
Это было во времена Win9x.
В 2000/XP/Server 2003 все гораздо лучше. Я не помню когда у меня последний раз был BSOD не по причине железа, вышедшего из строя.

Андрей Хропов wrote:
> ZEN> Даже в Mono сталкиваются с неожиданными трудностями по реализации
> точка-нет,
> Извините, .NET — это международный стандарт, который с Windows никак не
> связан.
Но тем не менее, единственная приличная его реализация есть только на
Windows. Кроме того, в этот стандарт не входят почти никакие библиотеки.

Здравствуйте, eao197, Вы писали:

E>Тем не менее, разговор свелся к обсуждению интеграции различных GUI приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и server side так же.

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

Здравствуйте, Cyberax, Вы писали:

C>Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего
C>текущего проекта предлагаете на сервер вынести?

Это зависит от расчета и от того, что является результатом расчета. Может быть его нужно не то что на один сервер, а на отдельный high perfomance кластер выносить.

iZEN wrote:
> ISO — вот это организация, причём международная, независимая от частных
> фирм и инвесторов. CLR ещё не входит в планы стандартизации на уровне ISO.
Для CLR уже есть ISO-стандарт, принятый через fast-track процесс.

> Ладно, берём вирус msblast, который выбивает сервис RPC с
> пользовательского уровня!!! Такое однозначно не пройдёт в *.NIX.
Sendmail?

Здравствуйте, eao197, Вы писали:

E>Тем не менее, разговор свелся к обсуждению интеграции различных GUI приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и server side так же.

Вообще я имел ввиду компонентно ориентированные технологии нативные для Linux OS, как например COM для виндов, а теперь и .NET. И вот чего я еще не понимаю в ваших рассуждениях это то, что КОП вы привязываете к ГУИ и серверных приложений. Исходя из своего опыта работы с GUIшными так и Server-Side проектами, могу сделать вывод, что разницы нет. Очень хорошим чистым и наглядным примером компонентно ориентированной технологии является на мой взгляд .NET. Ну так вот, покажите мне на его примере разницу при написании гуишных и серверных приложений ? .NET сам по себе компонентный. На мой взгляд (может и ошибочный) неверно разделять КОП для гуи и серверных приложений.

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

Здравствуйте, Cyberax, Вы писали:

C>Кстати, и откуда вы это знаете о моем опыте? Читали резюме? Видели мои
C>проекты? А?

Это у "них" по дефолту считается что все остальные дебилы и ламеры, а они "элита"

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Cyberax, Вы писали:

C>>Ау! Модераторы!
WH>Откуда отрезать?

Пушай здесь остается, тема как раз философская.

Здравствуйте, Kisloid, Вы писали:

K>Здравствуйте, eao197, Вы писали:

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

K>Возникает вопрос удобства использования,

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

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

Успокойтесь. Всё работает очень быстро. Посмотрите, например, на X11, где вся графика гоняется через unix domain socket, если локально, и через, например, tcp, если удалённо. И ничего, работает. Ну а для особо чувствительных задач — фильмы, игры — можно и shm заюзать, но обязательно оставив возможность обойтись без него, во имя священной Масштабируемости.