Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET. Знаю под линуксом есть мозилловская разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает до COM по качеству, скорости. Может я чего то упустил ?
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
K>Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET.
Ну так под Linux реализация .NET в виде Mono развивается постепенно.
Здравствуйте, Kisloid, Вы писали:
K>Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода.
Так поднапрягите воображение. На COM и .NET мир клином не сошелся.
У программистов Windows есть понятная склонность считать технологии МС верхом человеческой мысли. А то, что эти технологии меняются как в калейдоскопе их не заботит. Unix консервативен, в его мире книги Стивенса, вышедшие в начале 90-х, до сих пор сохраняют свою полезность и эта консервативность не мешает делать крупные проекты.
Здравствуйте, 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.
Здравствуйте, Quintanar, Вы писали:
Q>Так поднапрягите воображение. На COM и .NET мир клином не сошелся. Q>У программистов Windows есть понятная склонность считать технологии МС верхом человеческой мысли. А то, что эти технологии меняются как в калейдоскопе их не заботит. Unix консервативен, в его мире книги Стивенса, вышедшие в начале 90-х, до сих пор сохраняют свою полезность и эта консервативность не мешает делать крупные проекты.
Забавно, что есть много слов. Даже трое согласных с ними. И ни грамма по КОП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kisloid, Вы писали:
K>Вот мне очень интересно. Есть ли под линуксами компонентно ориентированное программирование ? Исходя из личного опыта, не могу себе представить крупный проект без компонентно ориентированного подхода. Под windows например COM, .NET. Знаю под линуксом есть мозилловская разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает до COM по качеству, скорости. Может я чего то упустил ?
Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП.
По последним новостям проекта Mono до сих пор не решены проблемы работы "компонентов" WinForms.
Здравствуйте, eao197, Вы писали:
E>Да, Unix way: [skipped]
Вот тогда следующий вопрос, возьмем к примеру Мозилловские проекты, зачем им надо было создавать свою реализацию КОМа если есть unix way (хотя наверное вопрос к ним ) ?
Какие примеры больших проектов написанных исключительно через unix way ? GAIM ?
После прочтения сложилось такое впечатление, что это ИМХО не очень удобно и влечет за собой кучу проблем.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, 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, пытается придумывать какие-то комбайны.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Kisloid, Вы писали:
. K>Вот тогда следующий вопрос, возьмем к примеру Мозилловские проекты, зачем им надо было создавать свою реализацию КОМа если есть unix way (хотя наверное вопрос к ним ) ?
А unix way — это непортабельно. Не везде есть приличный fork(), не везде нормально работают пайпы, не везде есть shell с набором стандартных утилит для связки компонентов (sed-ы всяческие с awk-ами).
K>Какие примеры больших проектов написанных исключительно через unix way ? GAIM ?
Сам Unix. Это же конструктор такой — что хочешь, то из него и лепишь.
K>После прочтения сложилось такое впечатление, что это ИМХО не очень удобно и влечет за собой кучу проблем.
Это впечатление обманчиво. Пока что я не встречал более удобной компонентной модели чем Unix way.
Во первых — удобная отладка — протоколы обмена между компонентами как правило текстовые.
Во вторых — масштабируемость на халяву.
В третьих — лёгкость сопряжения с посторонними компонентами и сопровождения изменений в них — достаточно встроить маленькую программку-фильтр, приводящую протокол обмена к нужному тебе формату.
В пятых — нет привязки к какому либо конкретному языку и рантайму.
Короче, недостатков этой модели я не вижу. Преимуществ — вагон.
Здравствуйте, iZEN, Вы писали:
ZEN>А кто сказал, что COM и .Net — компонентные технологии? ZEN>Они обе завязаны на реестр и Windows. Даже в Mono сталкиваются с неожиданными трудностями по реализации точка-нет, не говоря уже о реализации COM на не-MS-платформах. Эти т.н. "компонентные технологии" не являются таковыми, так как компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают.
ZEN>В Linux компонентно всё: от ядра до процессов пользовательского уровня. Например, оконная система X Window работает с ядром и пользовательскими процессами по чётко специфицированным протоколам, позволяющим запускать пользовательские процессы на одном компьютере, а следить за ним с красивым GUI на другом компьютере. Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.
ZEN>P.S. В GNOME Desktop Environment штатно работает ORBit — CORBA сервер — аналог поддержки OLE/DCOM в Windows.
Вопрос.
Если "В Linux компонентно всё" и "компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают", то почему я не наблюдаю XWindows под ОС Windows или MSDOS?
Дядя Билл запретил?
Здравствуйте, DJ KARIES, Вы писали:
DK>Вопрос. DK>Если "В Linux компонентно всё" и "компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают", то почему я не наблюдаю XWindows под ОС Windows или MSDOS? DK>Дядя Билл запретил?
Не XWindows, а XWindow. X-сервера под Windows есть, и не один. Например, WinaXe, XWinLogon, XWin32, eXceed.
Здравствуйте, DJ KARIES, Вы писали:
DK>Если "В Linux компонентно всё" и "компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают", то почему я не наблюдаю XWindows под ОС Windows или MSDOS? DK>Дядя Билл запретил?
Здравствуйте, eao197, Вы писали:
E>Может просто плохо смотришь? http://www.interix.com/InteropToolworks.htm, http://x.cygwin.com/ E>
Дело в том, что распростанённость этого чуда весьма низка...
Отсюда мораль, выживает тот, кто выживает (кого-то). (тобишь мелкомягкие)
Здравствуйте, DJ KARIES, Вы писали:
DK>Дело в том, что распростанённость этого чуда весьма низка...
Ваша заява никак не вписывается в логику предыдущего вашего же утверждения.
Знаете, есть такой пренеприятнейший тип людей, кто не способен признавать свои ошибки и всячески старается их замазать и заболтать. Так, к сведению.
DK>Отсюда мораль, выживает тот, кто выживает (кого-то). (тобишь мелкомягкие)
А что, с X-Window что-то случилось? Вроде бы очень даже неплохо выживает. Что бы там всякие малограмотные не вещали.
Kolhoz wrote: > Короче, недостатков этой модели я не вижу. Преимуществ — вагон.
Нет недостатков???? Их куча!
1. Невозможность нормального "обратного" общения. Программы в пайпах не
могут нормально передать информацию "выше" по цепочке.
2. Или ограниченность простыми текстовыми данными, или необходмость
парсить данные в каждой программе.
3. Плохая совместимость со структурированными данными.
4. С бинарными данными еще хуже.
И т.п.
Здравствуйте, iZEN, Вы писали:
ZEN>.... Приложения ведут себя иначе — не как в Windows, где Explorer или глючное пользовательское приложение легко может свалить всю систему в BSOD.
Чооо ????
В WinNT user-land приложение валит систему? Из под ограниченного аккаунта (не админ)?
Ну-ка пример (только без использования эксплоитов, ибо сие и в никсах есть).
Здравствуйте, Cyberax, Вы писали:
C>1. Невозможность нормального "обратного" общения. Программы в пайпах не C>могут нормально передать информацию "выше" по цепочке.
Не пайпом единым... Открываем кого либо через popen(), и общаемся в обе стороны.
C>2. Или ограниченность простыми текстовыми данными, или необходмость C>парсить данные в каждой программе.
Это ни фига не недостаток. Это огромнейшее преимущество!!!
C>3. Плохая совместимость со структурированными данными.
Чушь. Офигенная совместимость — можно хорошие и правильные S-выражения гонять, можно глупый попсовый XML, можно любые бинарные форматы — кому что в голову взбредёт.
C>4. С бинарными данными еще хуже.
Да? tar -xf — бла-бла-бла | bzip2
Или того лучше, dvgrab — | mpeg2encode ...
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 не по причине железа, вышедшего из строя.
Kolhoz wrote: > C>1. Невозможность нормального "обратного" общения. Программы в пайпах не > C>могут нормально передать информацию "выше" по цепочке. > Не пайпом единым... Открываем кого либо через popen(), и общаемся в обе > стороны.
А все равно. Нет нормального механизма передачи исключительных ситуаций.
> C>2. Или ограниченность простыми текстовыми данными, или необходмость > C>парсить данные в каждой программе. > Это ни фига не недостаток. Это огромнейшее преимущество!!!
Недостаток. Кроме простого текста есть:
1. XML
2. JSON
3. Да хотя бы ini-файлы
4. Файлы с многострочными значениями
> C>3. Плохая совместимость со структурированными данными. > Чушь. Офигенная совместимость — можно хорошие и правильные S-выражения > гонять, можно глупый попсовый XML, можно любые бинарные форматы — кому > что в голову взбредёт.
Какие стандартные утилиты догадаются, что последовательность ಩ (код
вымышлен) — это буква "а"? Правильно, никакие.
Значит надо как-то канонизировать документы, включая в пайпы
дополнительные программы. И прощай простота.
> C>4. С бинарными данными еще хуже. > Да? tar -xf — бла-бла-бла | bzip2
А как там у нас grep будет работать, например?
Кстати еще минус — отсутствие методов работы с непотоковыми данными. То
есть "cat somefile | rar | mail ..." уже не сделать — так как
rar'у нужен произвольный доступ для создания solid-архивов.
Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
случае в юниксах эта задача не решается).
> Что и т.п.? Вы уж что либо более похожее на недостатки назовите. С > конкретными примерами применений, где эти недостатки явственно > проявляются. Не надо одних только голословных заявлений, ок?
Да пожалуйста, сколько угодно.
Мой любимый пример: как мне таблицу с графиками из Calc вставить в
AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
Я не спорю, pipe'ы — это очень элегантное решение, позволяющее
эффективно решать большую часть административных задач. Только
вот пора бы уже что-то новое придумать.
Андрей Хропов wrote: > ZEN> Даже в Mono сталкиваются с неожиданными трудностями по реализации > точка-нет, > Извините, .NET — это международный стандарт, который с Windows никак не > связан.
Но тем не менее, единственная приличная его реализация есть только на
Windows. Кроме того, в этот стандарт не входят почти никакие библиотеки.
Здравствуйте, Cyberax, Вы писали:
C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора?
Порочный подход. В результате получится только глючная помойка, как микрософис.
Каждая программа должна делать свое дело. А в третей все должно интегрироватся. Никто же не жалуется, что нет возможности редактировать флеш ролик прямо на веб-странице.
Kluev wrote: > C>Мой любимый пример: как мне таблицу с графиками из Calc вставить в > C>AbiWord, а потом ее там же редактировать с помощью inplace-редактора? > Порочный подход. В результате получится только глючная помойка, как > микрософис.
По странному совпадению, МСОффис безглючнее своих конкурентов.
> Каждая программа должна делать свое дело.
Именно. Word редактирует документ, Excel редактирует таблицы и т.п.
> А в третей все должно интегрироватся.
Как?
> Никто же не жалуется, что нет возможности редактировать флеш ролик > прямо на веб-странице.
На веб-странице — нет. А вот уметь это делать из дизайнера
страниц было бы очень удобно во многих случаях.
Просто с OLE произошло все то, что происходит с продуктами MS — "хотели
как лучше, а получилось как всегда". Вместо compound documents можно
было бы использовать простые zip-файлы (как в OO), вместо моникеров —
обычные URL. И тогда OLE выглядел бы намного приятнее.
Здравствуйте, Cyberax, Вы писали:
>> Не пайпом единым... Открываем кого либо через popen(), и общаемся в обе >> стороны. C>А все равно. Нет нормального механизма передачи исключительных ситуаций.
Как нет? Оно обычно в протокол зашито. Ни разу с этим трудностей не испытывал.
>> C>2. Или ограниченность простыми текстовыми данными, или необходмость >> C>парсить данные в каждой программе. >> Это ни фига не недостаток. Это огромнейшее преимущество!!! C>Недостаток. Кроме простого текста есть: C>1. XML
Это — простой текст. Только очень дерьмовый простой текст. У меня всегда практически для обмена структурированной информацией S-выражения используются.
C>2. JSON C>3. Да хотя бы ini-файлы C>4. Файлы с многострочными значениями
И? Где тут проблемы, а?
C>Какие стандартные утилиты догадаются, что последовательность ಩ (код 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>По странному совпадению, МСОффис безглючнее своих конкурентов.
Он глючен имманентно, уже на уровне самой идеологии. Как бы чисто идеологию не реализовывали, она останется глючной.
>> Каждая программа должна делать свое дело. C>Именно. Word редактирует документ, Excel редактирует таблицы и т.п.
И не фиг их смешивать.
Правда, с другой стороны, Unix way ну нисколечко не мешает сделать такой (пусть и совершенно ненужный) GUI. См., к примеру, wxMaxima.
>> А в третей все должно интегрироватся. C>Как?
См. мой пример.
>> Никто же не жалуется, что нет возможности редактировать флеш ролик >> прямо на веб-странице. C>На веб-странице — нет. А вот уметь это делать из дизайнера C>страниц было бы очень удобно во многих случаях.
Идиотизм.
C>Просто с OLE произошло все то, что происходит с продуктами MS — "хотели C>как лучше, а получилось как всегда". Вместо compound documents можно C>было бы использовать простые zip-файлы (как в OO), вместо моникеров — C>обычные URL. И тогда OLE выглядел бы намного приятнее.
Вообще, странные вы люди, вендузятники. Кроме как про "документы" ни про что иное и думать не в состоянии. Ваш мирок ограничен "офисом".
Kolhoz wrote: > C>А все равно. Нет нормального механизма передачи исключительных ситуаций. > Как нет? Оно обычно в протокол зашито. Ни разу с этим трудностей не > испытывал.
Проблема если нужно одновременно два разных потока данных как-то передавать.
> C>Недостаток. Кроме простого текста есть: > C>1. XML > Это — простой текст. Только очень дерьмовый простой текст. У меня всегда > практически для обмена структурированной информацией S-выражения > используются.
S-выражения — те же яйца, вид в профиль.
Как-то надо было сделать простую вещь — взять XML, пробежаться по всем
узлам с заданым путем, взять у них атрибут, сделать операцию с этим
атрибутом (это было имя файла, надо было regexp'ом его переименовать), а
потом записать его же в этот документ, но по другому пути.
После часа мучений с tee и прочими гадостями — просто взял
ActivePython+MSXML и за 10 минут написал все что нужно.
> C>2. JSON > C>3. Да хотя бы ini-файлы > C>4. Файлы с многострочными значениями > И? Где тут проблемы, а?
Неудобно использовать стандартные утиллиты.
> C>Какие стандартные утилиты догадаются, что последовательность ಩ (код > 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, Вы писали:
K> Вообще, странные вы люди, вендузятники. Кроме как про "документы" ни про что иное и думать не в состоянии. Ваш мирок ограничен "офисом".
Коллеги, настоятельная просьба не скатываться на выяснение отношений и на очередной виток священной войны Unix vs Windows. Если есть желание вывалять себя в грязи, то пожалуйста в Священные Войны.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Андрей Хропов wrote: >> ZEN> Даже в Mono сталкиваются с неожиданными трудностями по реализации >> точка-нет, >> Извините, .NET — это международный стандарт, который с Windows никак не >> связан. C>Но тем не менее, единственная приличная его реализация есть только на C>Windows. Кроме того, в этот стандарт не входят почти никакие библиотеки.
Ну я соглашусь, но компонентность то заложена в сам стандарт.
DK>Вопрос. DK>Если "В Linux компонентно всё" и "компонентные технологии должны быть не зависимы от низкоуровневой программной платформы, на которой они работают", то почему я не наблюдаю XWindows под ОС Windows или MSDOS?
Потому что плохо смотришь. Cygwin/X, XWin32, Exceed и еще пачка.
Здравствуйте, Kolhoz, Вы писали:
K> Обе эти убогонькие программульки никакого отношения к unix way не имеют. А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в одну систему, и, как показывает практика, вендовозные ламеры, любители поредактировать табличку в текстовом процессоре, по эффективности работы просто рядом не валялись с теми кто пользуется подобной связкой. Пара дней — и идеального полиграфического качества статья готова, с идеальными графиками и достоверно проверенным качеством вывода и рассчётов. Вордописцы будут с тем же самым возиться не меньше месяца, как, опять же, демонстрирует та же самая практика.
Кстати да, после некоторого опыта работы с LaTeX меняется подход к написанию документов. Особенно, когда используешь собственные команды (либо собственные verbatim, или собственные колонтитулы) и одним легким движением руки изменяешь оформление всех однотипных фрагментов во всем документе -- это впечатляет.
Но, нужно отдавать отчет о том, что использование подобных инструментов требует от пользователя более длительного обучения. Имхо, это обучение окупается сторицей, но далеко не все согласны на это пойти (как по объективным, так и по субъективным причинам). Поэтому наезды от сторонников "дружественного к пользователям" подхода к сторонникам "дружественного к специалистам" подхода будут всегда. И будут носить, имхо, скорее эмоциональный, нежели рациональный характер.
Тем не менее, разговор свелся к обсуждению интеграции различных GUI приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и server side так же.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее C>эффективно решать большую часть административных задач. Только C>вот пора бы уже что-то новое придумать.
Есть мнение, что надо руководствоваться не религиозным чувством, а прагматизмом.
Если проще через пайпы — то через пайты. Если пайпы не катят — то пожалуйста: CORBA, DCOP и
черти-что еще. Примеры — KDE, KParts.
dmz>Есть мнение, что надо руководствоваться не религиозным чувством, а прагматизмом. dmz>Если проще через пайпы — то через пайты. Если пайпы не катят — то пожалуйста: CORBA, DCOP и dmz>черти-что еще. Примеры — KDE, KParts.
Здравствуйте, 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 читаю и смеюсь.
Нет тут фанатизма. Есть знания и опыт, которых нет у вас.
Здравствуйте, eao197, Вы писали:
E>Тем не менее, разговор свелся к обсуждению интеграции различных GUI приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и server side так же.
Так и я о том же. Виндоводы при упоминании компонентов сразу рюшечки-менюшечки воображают да композитные документы. Чем сразу выдают свой стиль мышления — от формы к содержанию. Доверять таким людям разработку архитектуры сложных систем — самоубийство, они любую архитектуру будут от GUI проектировать. Особенно этим отлечаются дельфины, в них собрана вся квинтэссенция махрового виндуизма.
Здравствуйте, dmz, Вы писали:
dmz>Есть мнение, что надо руководствоваться не религиозным чувством, а прагматизмом. dmz>Если проще через пайпы — то через пайты. Если пайпы не катят — то пожалуйста: CORBA, DCOP и dmz>черти-что еще. Примеры — KDE, KParts.
Дык. Но, однако, что характерно — любая, сколь угодно сложная объектная (или ещё какая) компонентная модель влёт реализуется поверх фундаментальной модели unix way. Тогда как обратное неверно.
eao197 wrote: > Кстати да, после некоторого опыта работы с LaTeX меняется подход к > написанию документов. Особенно, когда используешь собственные команды > (либо собственные verbatim, или собственные колонтитулы) и одним легким > движением руки изменяешь оформление всех однотипных фрагментов во всем > документе -- это впечатляет.
Ворд это тоже позволяет делать И свои библиотеки стилей в том числе.
> Тем не менее, разговор свелся к обсуждению интеграции различных GUI > приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и > server side так же.
С server-side в Unix все нормально.
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 деньги и зарабатывает.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Kolhoz, Вы писали:
K> Так и я о том же. Виндоводы при упоминании компонентов сразу рюшечки-менюшечки воображают да композитные документы. Чем сразу выдают свой стиль мышления — от формы к содержанию. Доверять таким людям разработку архитектуры сложных систем — самоубийство, они любую архитектуру будут от GUI проектировать. Особенно этим отлечаются дельфины, в них собрана вся квинтэссенция махрового виндуизма.
Давайте все-таки без экстремизма и максимализма. Битие определяет сознание. Если кому-то приходится лабать околоофисный софт под Windows, то тут хочешь не хочешь, а с установленными MS (и миллионами не технических пользователей) правилами приходится считаться. Все же главная цель программы -- это выполнение возложенных на нее обязанностей. Внутренняя архитектура покупателей не интересует.
Поэтому лучше не издеваться над теми, кто на подобной GUI-ёвой компонентности деньги зарабатывает, а рассказывать о том, что что-то можно делать совсем по другому. Чтобы не было дилетантских вопросов "Как же в Linux-е без OLE?".
Так что предлагаю не смеятся друг над другом, а учиться друг у друга
Чей-то я в пацифисты записался вдруг?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
dmz wrote: > C>Я не спорю, pipe'ы — это очень элегантное решение, позволяющее > C>эффективно решать *большую часть* административных задач. Только > C>вот пора бы уже что-то новое придумать. > Есть мнение, что надо руководствоваться не религиозным чувством, а > прагматизмом. > Если проще через пайпы — то через пайты. Если пайпы не катят — то > пожалуйста: CORBA, DCOP и черти-что еще. Примеры — KDE, KParts.
А вот тут проявляются проблемы — эти механизмы не совместимы между друг
другом. Да и по мощности эти компонентные системы уступают (или только
приближаются к) OLE2.
Здравствуйте, eao197, Вы писали:
E>Давайте все-таки без экстремизма и максимализма. Битие определяет сознание. Если кому-то приходится лабать околоофисный софт под Windows, то тут хочешь не хочешь, а с установленными MS (и миллионами не технических пользователей) правилами приходится считаться. Все же главная цель программы -- это выполнение возложенных на нее обязанностей. Внутренняя архитектура покупателей не интересует.
Не согласен. Если разработчики дизельных двигателей начнут их проектировать исходя из цвета и формы кузова автомобиля, под который делается движок, а так же при первоначальной оценке проекта обязательно учитывать обивку кресел — то это будет просто смешно.
GUI вторично всегда, даже в самом юзер-ориентированном проекте. И разработчик просто не имеет ни малейшего права выводить архитектуру приложения исходя из своих представлений о GUI. Такому разработчику в индустрии не место.
E>Поэтому лучше не издеваться над теми, кто на подобной GUI-ёвой компонентности деньги зарабатывает, а рассказывать о том, что что-то можно делать совсем по другому. Чтобы не было дилетантских вопросов "Как же в Linux-е без OLE?".
Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, преимущественно под Windows, и ну ни разу не приходилось применять их, вендовый стиль мышления. К чему бы это?
E>Так что предлагаю не смеятся друг над другом, а учиться друг у друга
Боюсь, мне у них учиться нечему... У нас ведь и так есть всё то же что и у них. Наигрались в прошлом и выкинули на помойку — а они, вендузятники, подобрали. И объектные компонентные модели были, и унифицированные рантаймы. Всякого добра хватало. Много лет назад отбраковали.
Здравствуйте, Kolhoz, Вы писали:
K> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, преимущественно под Windows, и ну ни разу не приходилось применять их, вендовый стиль мышления. К чему бы это?
E>>Так что предлагаю не смеятся друг над другом, а учиться друг у друга
K> Боюсь, мне у них учиться нечему... У нас ведь и так есть всё то же что и у них. Наигрались в прошлом и выкинули на помойку — а они, вендузятники, подобрали. И объектные компонентные модели были, и унифицированные рантаймы. Всякого добра хватало. Много лет назад отбраковали.
Имхо, научится всегда есть чему, но это уже офтопик.
На самом деле меня больше волнует качество обсуждений в Философии Программирование, которое в последнее время регулярно снижается. Интересные темы превращаются в пустые флеймы, а затем переносятся в Священные Войны с теми редкими крупицами полезной информации, которые там все же есть.
Я это к тому, что высказывания типа "виндузятники", "невозможно поменять стиль мышления", "мне научиться не чему" как раз превращают обмен мнениями в бесполезный флейм. Вот я и призываю держать себя в руках, чтобы вот так
Kolhoz wrote: > C>Проблема если нужно одновременно два разных потока данных как-то > передавать. > ??? > Ни разу не проблема.
Как через один пайп передать два потока одновременно? Только named pipe'ами.
> C>S-выражения — те же яйца, вид в профиль. > Не те же. Обработка проще и дешевле. И вместе с ними можно передавать код, > не только данные.
Как мне из JavaScript прочитать S-expr? Упс... А как там с разными
кодировками?
> C>Как-то надо было сделать простую вещь — взять XML, пробежаться по всем > C>узлам с заданым путем, взять у них атрибут, сделать операцию с этим > C>атрибутом (это было имя файла, надо было regexp'ом его переименовать), а > C>потом записать его же в этот документ, но по другому пути. > И? Где трудности? Вставить в пайплайн xslt кто запретил?
А как мне из xslt вызвать файловые операции со сторонними файлами?
> C>После часа мучений с tee и прочими гадостями — просто взял > C>ActivePython+MSXML и за 10 минут написал все что нужно. > И чем же это не unix way?
COM ведь используется.
Создается компонент (написанный на С++) и прозрачно используется из
совершенно другого языка (о котором создатель компонента мог и не
догадываться).
Это я к тому, что Unix-pipes — это далеко не идеал.
> Этих стандартных утилит — вагон. На все случаи жизни хватит. Для меня > самые "стандартные" — perl и python.
И что? Тот же Word замечательно рулится через OLE2 из
Python/Perl/VisualBasic/Brainfuck (да!)/C#/Nemerle/....
> C>Без стандартных утиллит — получается простая идеология использования > C>соединенных фильтров. > Это и есть unix way. Много маленьких уединённых программок с CLI, > способных общаться через пайпы И СОКЕТЫ.
Вот только этот мирок разбивается, когда встречается с суровыми
реальностями настоящих требований пользователей.
> C>Нет. Это убогий unix way — так как RAR поддерживает создание архивов с > C>кодами коррекции ошибок (если повреждается часть файла — ее можно > C>восстановить). Но для этого ему нужен произвольный доступ к источнику и > C>результату. > Нужен произвольный доступ — значит, не нужен поток и масштабируемость. > Выбирай.
А мне хочется и того и другого. И я это могу получить, используя более
мощные абстракции.
В частности, для данного примера хватило бы возможности реализовывать
свои потоки произвольного доступа. В OLE это УЖЕ есть — смотри IStream.
>> > ЗАЧЕМ?!? Named pipes и unix domain sockets рулят со страшной >> > силой. > C>Покажите мне fseek на named pipe или domain socket. > Зачем?
А вы думаете, что мир заканчивается однонаправленными потоками?
> C>Можно использовать shmem с некоторыми ограничениями, но все равно не > C>хватает возможности полноценно реализовать свой файл. > Зачем? Тем более shmem не масштабируется, так что фтопку.
Именно в этом и проблема с ним.
> Какие факты? Есть две ущербные программульки, про unix way ничего не > знающие — так какое они имеют отношение тогда к обсуждаемой теме?
Есть 99% рынка домашних компьютеров, занятых этими ущербными программами.
А многочисленные попытки приспособить The Unix Way к десктопу — провалились.
> C>Пробовал. > Плохо пробовали. Неумело.
Я не ежик, чтобы колоться, но продолжать жрать кактус. Причем без
какой-то перспективы на улучшение.
> C> ОЧЕНЬ неудобно писать спеки — если в Word/OpenOffice/... я > C>могу запустить редактор, нарисовать нужную диаграмму, cut&paste'ом > C>вставить в документ (не волнуюясь при этом об именах файлов), то с TeXом > C>один ужас получается. > Какие такие спеки?!? Для тех. документации есть docbook. А тех, кто > пишет её в офисах — надо гнать в три шеи, им в IT не место.
Еще раз медленно, для тех кто долго понимает:
Технические спецификации — это НЕ документация к коду, это НЕ
документация к существующим системам, их НЕ нужно иметь в 10 форматах,
они ДОЛЖНЫ удобно редактироваться.
> C>Начиная с неправильных версий пакетов и стилей на разных компьютерах, и > C>заканчивая неполными документами. > Ну ну. Не умеете вы этих кошек готовить.
Ага. А может это просто кто-то много о себе думает?
> C>Понимаете, мне *НАФИГ НЕ НУЖНЫ* документы полиграфического > C>качества, так работа идет с электронными копиями (а печатаются они для > C>отчетности). > Тогда какие на хрен вордоофисы? Это задача для docbook.
Docbook не подходит по многим причинам:
1. Редактировать руками его неудобно.
2. Нет нормальных редакторов.
3. Куча ненужных возможностей.
4. Нет НУЖНЫХ возможностей.
> C>Плохие вордописцы. Или они там формулы рисуют? > Естественно рисуют.
Тогда действительно нафиг такое.
> C>Хотя в TeXе очень неудобно писать химические формулы (точнее, их вообще > C>неудобно как-либо в текстовом виде записывать). > Удобно, очень удобно. Удобней чем любой визуальный редактор. > Даже диаграммы Фейнмана — и то удобно, куда уж там всякой попсовой химии.
Ты просто не видел формул. Их и в 2D (на листе бумаги) неудобно иногда
рисовать, а уж в 1D — вообще невозможно.
Диаграммы Фейнмана — это десткий лепет по сложности рисования.
> C>ROTFL. > Это вы от незнания.
Задумайтесь, всякое общее утверждение — неверно.
> C>Как раз GUI — это идеальный пример для "компонентов" в понимании > C>COM/.NET/Delphi. > Отвратительный пример.
А что делать? Мир — жестокая штука.
> Идеальный GUI — это, например, Tcl/Tk, с частичной генерацией кода на > стороне логики. Другой вариант — сервер, отображающий визуальные > компоненты, которые описываются в виде XML или S-выражений.
А кто описания строит? Если автомат — то в морг.
Ну а задавать расположение визульных компонентов вручную с помощью
layout'ов (которые можно описывать как угодно) — додумались уже давным
давно.
> Всякой дебильной объектщине в GUI и близко места нет. То, что > извращенцы-объектщики так нагло и упорно в GUI лезут — ни разу им не > оправдание.
Ну так функциональщики показали бы класс.
> Нет тут фанатизма. Есть знания и опыт, которых нет у вас.
Вы случайно не Луговской? Что-то стиль похож.
Кстати, и откуда вы это знаете о моем опыте? Читали резюме? Видели мои
проекты? А?
Здравствуйте, Cyberax, Вы писали:
C>Ворд это тоже позволяет делать И свои библиотеки стилей в том числе.
А я вам не верю. Попробуйте ка встроить мне в Ворд **ВЕКТОРНУЮ** графику, созданную в Wolfram Mathematica. Так, чтоб пересчитывалось при изменении исходных данных, вписанных в тот же самый вордовы документ. И при этом чтоб его можно было прочитать на компьютере, где Mathematica не установлена.
Да и сами посудите — много ли можно наавтоматизировать на Вижуал Васике?!?
C>С server-side в Unix все нормально.
При правильном проектировании любой, сколь угодно сложный ГУЙ — это тонюсенькая (и легкоотрываемая) прослоечка над "server-side".
>> Ни разу не проблема. 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>Вы случайно не Луговской? Что-то стиль похож.
C>Кстати, и откуда вы это знаете о моем опыте? Читали резюме? Видели мои C>проекты? А?
Здравствуйте, kan_izh, Вы писали:
_>Вот именно что _ламеры_. А дай ламеру твой unix way, он и за год не справится. А не ламеры и в ворде шустро шуруют.
Фига. В ворде просто нет нужных не-ламеру фичей. Либо есть, но добраться до них — слишком трудно и долго.
_>Попробуй потратить 2 недели обучая свою бабушку/маму word+excel для создания документа с парой графиков и mysql+tex на _>те же 2 недели. О результатах расскажи.
Практика показывает, что двух недель более чем достаточно для обучения latex-у и сопутствующей обвязке. Кого угодно, причём, от библиотекарши до секретарши. С Вордом труднее — ни хрена не понимают, боятся и зовут эникейщика на каждый чих.
Здравствуйте, Андрей Хропов, Вы писали:
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.
Kolhoz wrote: > Не согласен. Если разработчики дизельных двигателей начнут их > проектировать исходя из цвета и формы кузова автомобиля, под который > делается движок, а так же при первоначальной оценке проекта обязательно > учитывать обивку кресел — то это будет просто смешно.
А если не учитывать форму кузова, то в итоге получится автомобиль
советского производства.
> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, > преимущественно под Windows, и ну ни разу не приходилось применять их, > вендовый стиль мышления. К чему бы это?
Ну так покажите эти GUI. И их пользователей. Какие проблемы?
Kolhoz wrote: > А я вам не верю. Попробуйте ка встроить мне в Ворд **ВЕКТОРНУЮ** > графику, созданную в Wolfram Mathematica. Так, чтоб пересчитывалось при > изменении исходных данных, вписанных в тот же самый вордовы документ. И > при этом чтоб его можно было прочитать на компьютере, где Mathematica не > установлена.
С Mathematica так не получится (она OLE2 не поддерживает).
А вот с Visio — вполне. Данные к диаграмме (таблица какая-нибудь,
например) привязываются через OLE Linking, все это сохраняется в
документ. На компьютерах, где нет Visio будет использоваться сохраненное
WMF-описание встроенного объекта.
> Да и сами посудите — много ли можно наавтоматизировать на Вижуал Васике?!?
Да сколько угодно:
1. VB — сам по себе вполне нормально подходит для автоматизации.
2. Делается внешний компонент и подключается к Word'у через механизм
Addin'ов.
3. Управляем Word'ом полностью из внешней системы (через OLE2, на любом
языке, в том числе и на Haskell).
> C>С server-side в Unix все нормально. > При правильном проектировании любой, сколь угодно сложный ГУЙ — это > тонюсенькая (и легкоотрываемая) прослоечка над "server-side".
Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего
текущего проекта предлагаете на сервер вынести?
Здравствуйте, Cyberax, Вы писали:
C>Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего C>текущего проекта предлагаете на сервер вынести?
Это зависит от расчета и от того, что является результатом расчета. Может быть его нужно не то что на один сервер, а на отдельный high perfomance кластер выносить.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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, опытным быть не может просто по определению.
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 от всех АйТи специалистов "которым не место в АйТи") Вот честное слово, хоть в мед энциклопедию вводи термин "синдром линуксоида" (можете читать как "синдром чувства элитизма"). Ничего против Линукса не имею, ибо сам год назад перешел, я даже ЗА! Но когда вот приходят товарищи "линуксоиды" говорят что я ламер виндовый, становится тошно и хочется плюнуть на эту ОС и быть среди более адекватных людей.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Cyberax, Вы писали:
>> C>С server-side в Unix все нормально. >> При правильном проектировании любой, сколь угодно сложный ГУЙ — это >> тонюсенькая (и легкоотрываемая) прослоечка над "server-side". C>Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего C>текущего проекта предлагаете на сервер вынести?
Ну формально легко выносится, даже OpenGL именно на этой идеологии построен
Здравствуйте, eao197, Вы писали:
K>> Боюсь, мне у них учиться нечему... У нас ведь и так есть всё то же что и у них. Наигрались в прошлом и выкинули на помойку — а они, вендузятники, подобрали. И объектные компонентные модели были, и унифицированные рантаймы. Всякого добра хватало. Много лет назад отбраковали.
E>Имхо, научится всегда есть чему, но это уже офтопик.
Увы, увы. Я в дао виндового программувания не обнаружил ни-че-го, что не было бы когда либо уже опробовано и отброшено за ненадобностью в мире более серьёзных разработок.
Если вы думаете, что я не знаю, как они мыслят, не знаю их методов и технологий — то вы ошибаетесь. Вынужденно касался этой гадости. А вот они почему-то не желают даже знать наших методов. Ленятся, что ли?
Здравствуйте, Cyberax, Вы писали:
C>А если не учитывать форму кузова, то в итоге получится автомобиль C>советского производства.
Почему тогда Форд свой Zeltec пихает и в седаны, и в хетчбеки?
C>Ну так покажите эти GUI. И их пользователей. Какие проблемы?
Зачем? Я уже приводил пример того, что ещё лучше и что общеизвестно. Вы пример проигнорировали (понимаю, понимаю, неудобные аргументы лучше всего просто не замечать).
Здравствуйте, Kisloid, Вы писали:
E>>Тем не менее, разговор свелся к обсуждению интеграции различных GUI приложений. Интересно, имел ли в виду Kisloid именно GUI? Или же и server side так же.
K>Вообще я имел ввиду компонентно ориентированные технологии нативные для Linux OS, как например COM для виндов, а теперь и .NET. И вот чего я еще не понимаю в ваших рассуждениях это то, что КОП вы привязываете к ГУИ и серверных приложений. Исходя из своего опыта работы с GUIшными так и Server-Side проектами, могу сделать вывод, что разницы нет. Очень хорошим чистым и наглядным примером компонентно ориентированной технологии является на мой взгляд .NET. Ну так вот, покажите мне на его примере разницу при написании гуишных и серверных приложений ? .NET сам по себе компонентный. На мой взгляд (может и ошибочный) неверно разделять КОП для гуи и серверных приложений.
Боюсь, что на примере .NET показать не смогу, ибо не .NET-овский я специалист.
Только вот unix way строится на том, чтобы иметь несколько небольших приложений, каждый из которых выполняет отдельную задачу и которые общаются друг с другом с помощью простых коммуникационных механизмов. Из этого следует, что если есть server side приложение, которое должно выполнять задачи A, B, C и D, то в духе unix будет не размещать все это в одном монолитном приложении, а запускать отдельными процессами, каждый из которых обрабатывает свою задачу. В зависимости от типа приложения эти процессы могут работать как параллельно (например, используя сокеты для взаимодействия), последовательно (как связка tar+gz или svnadmin+bzip2, или find+xarg+еще что-то), либо заменяя друг друга и передавая информацию друг другу либо в виде аргументов командной строки, либо через временные файлы.
Разделение лично я делаю потому, что для server side, который не имеет собственного интерактивного интерфейса все это дело можно спрятать за различными shell-файлами, демонами и прочим. В случае же с GUI необходимость редактирования или отображения составного документа в _одном_ окне какой-то программы должно означать, что все необходимые для отображения частей документа каким-то образом должны быть скомпанованы в одно общее приложение.
K>ЗЫ: честно говоря нет желания учавствовать в данной дискуссии т.к. как правильно отметили тема превратилась во флейм, прибежели "великие гуру" "линуксоиды", обозвали всех "глупыми виндузятниками"
Предлагаю не обращать внимание на подобные проявления экстремизма. Вести конструктивную дискусию в наших силах.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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, точно свободно доступна).
Просто постарайтесь поучиться правильно проектировать системы. Забудьте старые привычки, они вам очень мешают жить!
Здравствуйте, Kisloid, Вы писали:
K> Очень хорошим чистым и наглядным примером компонентно ориентированной технологии является на мой взгляд .NET.
?!?
В .NET из компонентностей есть только довольно примитивные формы RPC и сериализации и интерфейс ко всё тому же OLE. Ничего чистого и тем более наглядного не прослеживается — нет даже общей идеологии.
K> На мой взгляд (может и ошибочный) неверно разделять КОП для гуи и серверных приложений.
+1
K> да даже кто то предложил увольнять все кто пользуется вордом (таких наверное процентов 90 от всех АйТи специалистов "которым не место в АйТи")
А 90% и надо бы уволить. Тогда софт станет лучше и безглючнее. Вы поработайте для сравнения в команде, где весь документооборот на вордах, и в команде, где с одной стороны docbook, а с другой — bugzilla+cvszilla. Поймёте, почему вторая команда будет свысока смотреть на первую.
K> Но когда вот приходят товарищи "линуксоиды" говорят что я ламер виндовый, становится тошно и хочется плюнуть на эту ОС и быть среди более адекватных людей.
Ламер — не тот, кто пользуется виндовсом (я вот почти только под виндовс и писал всегда), а тот, кто не желает думать своей головой и ведётся на дешевый appeal to authority.
Я всячески пытаюсь свести данную дискуссию к обсуждению исключительно объекивных технических свойств разных компонентных моделей — но оппоненты постоянно скатываются на ту или иную гуманитарно-религиозную fallacy.
Здравствуйте, 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 активнее ищут, поэтому и больше находят. А так багов и в Линуксе хватает.
Здравствуйте, eao197, Вы писали:
E>Только вот unix way строится на том, чтобы иметь несколько небольших приложений, каждый из которых выполняет отдельную задачу и которые общаются друг с другом с помощью простых коммуникационных механизмов.
Возникает вопрос удобства использования, надежности и скорости данных механизмов. Вот все время слышу пайпы. Рассмотрим именованные (т.к. пока не интересует взаимодействие процессов родитель-потомок), по сути это есть файлы с дисциплиной организации fifo. Вот исходя из того что это есть файл у меня возникает такое смутное сомнение что оно будет медленным. Самому их пока не приходилось юзать, поэтому и спрашиваю
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Kolhoz wrote: > C>А если не учитывать форму кузова, то в итоге получится автомобиль > C>советского производства. > Почему тогда Форд свой Zeltec пихает и в седаны, и в хетчбеки?
Потому как специально было задизайнено с учетом обоих кузовов.
Или с кузова были сделаны под размер двигателя. Или ком
> C>Ну так покажите эти GUI. И их пользователей. Какие проблемы? > Зачем? Я уже приводил пример того, что ещё лучше и что общеизвестно.
Какой пример? wxMaxima? Я о нем и не слышал, хотя с учеными часто работаю.
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Только вот unix way строится на том, чтобы иметь несколько небольших приложений, каждый из которых выполняет отдельную задачу и которые общаются друг с другом с помощью простых коммуникационных механизмов.
K>Возникает вопрос удобства использования,
Опять же согласно принципу KISS в каждом случае используется наиболее удобный метод коммуникаций.
K> надежности и скорости данных механизмов. Вот все время слышу пайпы. Рассмотрим именованные (т.к. пока не интересует взаимодействие процессов родитель-потомок), по сути это есть файлы с дисциплиной организации fifo. Вот исходя из того что это есть файл у меня возникает такое смутное сомнение что оно будет медленным. Самому их пока не приходилось юзать, поэтому и спрашиваю
Успокойтесь. Всё работает очень быстро. Посмотрите, например, на X11, где вся графика гоняется через unix domain socket, если локально, и через, например, tcp, если удалённо. И ничего, работает. Ну а для особо чувствительных задач — фильмы, игры — можно и shm заюзать, но обязательно оставив возможность обойтись без него, во имя священной Масштабируемости.
Здравствуйте, Cyberax, Вы писали:
C>Потому как специально было задизайнено с учетом обоих кузовов.
Нет. Не обоих — их сильно больше, это одно время был самый популярный 1.6л движок.
C>Или с кузова были сделаны под размер двигателя.
Во! Начинаете понимать!
>> C>Ну так покажите эти GUI. И их пользователей. Какие проблемы? >> Зачем? Я уже приводил пример того, что ещё лучше и что общеизвестно. C>Какой пример? wxMaxima? Я о нем и не слышал, хотя с учеными часто работаю.
Wolfram Mathematica. Чистейший unix way в лучших его проявлениях. И с прозрачным интерфейсом к OLE2 при этом, только вот, не хватает силёнок у OLE для такой мощщи.
Здравствуйте, Cyberax, Вы писали:
C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем C>случае в юниксах эта задача не решается).
Читайте про VFS (виртуальная файловая система) и про интерфейс vnone/vfs, который чётко специфицирует организацию и функционирование любой произвольной файловой системы в UNIX. Это позволяет компонентным подходом решить задачу создания и поддержки собственной файловой системы. Этот интерфейс позволяет работать с любой файловой системой удалённо, по сети, прозрачно для пользователей и их процессов.
Через неё, кстати, "включили" "файловую" систему /proc, описывающую системные процессы, работающие в системе. Через неё приложения могут читать и писать в адресное пространство процессов. Это не pipe и не сокеты, это гораздо быстрее!
Kolhoz wrote: > C>Или с кузова были сделаны под размер двигателя. > Во! Начинаете понимать!
И? Это означает, что если что-то не делать, чтобы оно работало совместно
— то оно совместно работать не будет.
>> > C>Ну так покажите эти GUI. И их пользователей. Какие проблемы? >> > Зачем? Я уже приводил пример того, что ещё лучше и что общеизвестно. > C>Какой пример? wxMaxima? Я о нем и не слышал, хотя с учеными часто работаю. > Wolfram Mathematica. Чистейший unix way в лучших его проявлениях. И с > прозрачным интерфейсом к OLE2 при этом, только вот, не хватает силёнок у > OLE для такой мощщи.
OLE на интерфейс вааще пофиг. Он работает с прямоугольниками рисования и
объектами данных. Как их интерпретирует приложение — личное дело самого
приложения.
iZEN wrote: > C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию > C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем > C>случае в юниксах эта задача не решается). > Читайте про VFS (виртуальная файловая система) и про интерфейс > vnone/vfs, который чётко специфицирует организацию и функционирование > любой произвольной файловой системы в UNIX.
Еще раз. Вопрос был как мне добавить СВОЮ реализацию файла. И причем не
как драйвер в ядро.
Kisloid wrote: > Вот исходя из того что это есть файл у меня возникает такое смутное > сомнение что оно будет медленным. Самому их пока не приходилось > юзать, поэтому и спрашиваю
Смотря для чего. Из моей практики — файлы в tmpfs (файловая система,
оптимизированная под временные файлы) на Linux 2.6 работали гораздо
быстрее, чем pipe'ы для передачи 10-20Кб информации.
Однако pipe'ы очень удобно использовать, если нужно обработать большой
объем информации, так как при этом не нужна временная копия.
Здравствуйте, Cyberax, Вы писали:
>> Во! Начинаете понимать! C>И? Это означает, что если что-то не делать, чтобы оно работало совместно C>- то оно совместно работать не будет.
Нет. Это означает — сначала сделай хороший двигатель, а потом думай, какой кожей обивать кресла и какого цвета будет стрелка на спидометре.
C>OLE на интерфейс вааще пофиг. Он работает с прямоугольниками рисования и C>объектами данных. Как их интерпретирует приложение — личное дело самого C>приложения.
Вот вот. Это и есть — ущербный и ограниченный подход, который не позволяет делать даже самые простейшие вещи (см. пример задачи несколько ранее).
dmz wrote: > C>Как через один пайп передать два потока одновременно? Только named > pipe'ами. > А оно точно надо? В один поток — точно нельзя? Точно-точно?
В том случае было нельзя. Пришлось писать скрипт, который обрабатывал
эту ситуацию хитрым образом с помощью сигналов.
>> > И? Где трудности? Вставить в пайплайн xslt кто запретил? > C>А как мне из xslt вызвать файловые операции со сторонними файлами? > А это уже не поток. Работайте с файлами — но это уже другая история. > XML вообще формат, не рассчитанный на работу в потоковом стиле. > Вот хоть что делайте.
Именно. Но тем не менее, с XML замечательно можно работать компонентно:
получаем документ через SOAP, парсим MSXMLем, отдаем DOM-дерево скрипту
и т.п.
Просто это уже другая (неюниксовая) компонентность. Часто намного
более мощная, так как оперирует более мощными примитивами.
То что она более мощная не значит, что она лучше юниксовой модели —
просто у нее область применения другая.
Вот только тут некоторые товарищи считают, что все можно заключить в
прокрустово ложе пайпов и файлов в FS.
> C>COM ведь используется. > Я так понимаю, COM что бы MSXML дергать? Ну возьмите libxml которая есть в > питоне — и никакого кома.
Не было под рукой (я бы взял — мне MSXML не нравится). Просто это пример
как могут работать компоненты.
> C>Это я к тому, что Unix-pipes — это далеко не идеал. > Ничто — не идеал. Гвозди — молотком, шурупы — отверткой. Ы?
Ага.
> Боюсь все эти суровые нереализуемые требования в реале сведутся к требованию > воткнуть эхельную таблицу в ворд и там ее редактировать. Что в реальной > жизни и под виндовс умеет крайне мало приложений — например, эхельная таблица в > Лотус вставляется как картинка. Даже в html или rtf-не конвертируется.
Просто OLE2 — не очень простой для реализации интерфейс (MS, однако).
Его сами оффисные приложения, в основном, и поддерживают.
> С другой стороны, внутри офисных пакетов — и OO и вроде KOffice так умеют.
Умеют, но стабильно стали совсем недавно работать. А вот
inter-оффисность плохо работает
> С третьей стороны и телевизор (kmplayer) у меня вполне встраивается в > бровзер. > KParts — и не говорите что не стандарт. В рамках KDE такой-же стандарт, > как ActiveX в Win.
Да, но этих стандартов много. И друг с другом они не интероперируют
нормально.
> по моему, вам просто хочется разрушить мозг оппонента, уж извините.
"That will just be a completely unintentional side effect" (c) Linus
Torvalds
> Я таки не понял, если рару нужно random access то почему бы ему просто > не скормить файл? Из какого-то принципа? И чем в данном случае его поведение > отличается от его поведения под win?
В Win я могу создать IStream (поток с поддержкой seek'а) над своими
данными, и отдать его rar'у (а лучше 7-zip'у).
> Была где-то ссылка на статью, где убедително доказывалось, что KDE — это > Unix Way в полный рост. Стало быть, не провалились.
Я в KDE постоянно работаю. Не заметно Unix-way
> На самом деле, Unix way это не что иное, как принцип K.I.S.S. И ничего > более.
Э! Нет. Unix way — это Unix way.
eao197 wrote: > C>Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего > C>текущего проекта предлагаете на сервер вынести? > Это зависит от расчета и от того, что является результатом расчета. > Может быть его нужно не то что на один сервер, а на отдельный high > perfomance кластер выносить.
Проблема в том, что результат рассчета часто будет передаваться по сети
дольше, чем считаться.
Здравствуйте, Cyberax, Вы писали:
C>Просто это уже другая (неюниксовая) компонентность. Часто намного C>более мощная, так как оперирует более мощными примитивами.
Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным!
C>Вот только тут некоторые товарищи считают, что все можно заключить в C>прокрустово ложе пайпов и файлов в FS.
А сокеты как же?
C>В Win я могу создать IStream (поток с поддержкой seek'а) над своими C>данными, и отдать его rar'у (а лучше 7-zip'у).
И реализован он будет через временный файл. Оно нам надо?
Здравствуйте, Cyberax, Вы писали:
C>Проблема в том, что результат рассчета часто будет передаваться по сети C>дольше, чем считаться.
Он не может передаваться сильно дольше чем потребуется на его отображение.
Так что не надо предрассудков. Проверьте сначала. Я вот кроме графики уровня 3D-стрелялок ничего представить не могу, что требовало бы связывать в один контекст логику и отображение. А если таки потребуется — я всё равно unix way применю. Только внутри одного контекста. Не знаете, как? А вот я — знаю. Производительность будет неотличима от производительности прямого вызова API. Завидуете?
eao197 wrote: > C>Проблема в том, что результат рассчета часто будет передаваться по сети > C>дольше, чем считаться. > А подробнее? > По какой сети?
100Mbit. Да даже и гигабит не поможет.
> Какие объемы данных?
На входе массив точек — двумерная карта высот. На выходе — треугольная
сетка с индексами для некоторых операций.
Kolhoz wrote: > C>Проблема в том, что результат рассчета часто будет передаваться по сети > C>дольше, чем считаться. > Он не может передаваться сильно дольше чем потребуется на его отображение.
Ага.
Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3
секунды по незагруженной 100Мбит-сети).
На выходе примерно 500Мб информации (данные о треугольниках и индексы в
них).
> Так что не надо предрассудков. Проверьте сначала. Я вот кроме графики > уровня 3D-стрелялок ничего представить не могу, что требовало бы > связывать в один контекст логику и отображение.
У меня идет обработка данных с измерительных устройств.
> А если таки потребуется — я всё равно unix way применю.
Ага. И изображать данные будете через пайпы. А управлять вращениями
частей — задавая координаты кватернионов из командной строки.
> Только внутри одного контекста. Не знаете, как?
Через пайпы? Так это много ума не надо.
FR wrote: > C>Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего > C>текущего проекта предлагаете на сервер вынести? > Ну формально легко выносится, даже OpenGL именно на этой идеологии построен
Во-первых, отображение сгенерированных данных — это фигня. Залил display
list на сервер — и дальше просто меняешь ему преобразования.
Kolhoz wrote: > C>Просто это уже *другая* (неюниксовая) компонентность. Часто намного > C>более мощная, так как оперирует более мощными примитивами. > Опять 5*5... Эта компонентность не более мощная. Она более частная. Она > реализуется тривиально поверх примитивов unix way, а вот unix way поверх > объектной компонентной модели — нет. Не сравнивайте даже общее решение с > частным!
Мальчик, файл и VFS в юниксах — это классический пример объектного
дизайна. VFS — так это вообще textbook example для полиморфизма.
> C>Вот только тут некоторые товарищи считают, что все можно заключить в > C>прокрустово ложе пайпов и файлов в FS. > А сокеты как же?
Ой, да я про сокеты забыл. Они ведь все проблемы Вселенной решают.
> C>В Win я могу создать IStream (поток с поддержкой seek'а) над своими > C>данными, и отдать его rar'у (а лучше 7-zip'у). > И реализован он будет через временный файл. Оно нам надо?
Нет. Реализован он может быть как угодно. Лично делал IStream поверх
DB-блоба.
C>>Создается компонент (написанный на С++) и прозрачно используется из C>>совершенно другого языка (о котором создатель компонента мог и не C>>догадываться).
K> Какое извращение. Интерфейсы какие-то выдумывать... Гораздо проще — на любом языке создаётся компонент, который знает только про текстовые потоки и аргументы коммандной строки.
Как представлю себе десериализацию из тестового потока в каком-нить С++
Куда как лучше (не без помощи форума COM/DCOM/ActiveX) написать такое (отсылка факса с помощью Symantec WinFax Pro):
Mamut wrote: > Как представлю себе десериализацию из тестового потока в каком-нить С++
Сейчас вам скажут, что надо использовать S-выражения, которые еще и
выполняться сами могут
C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3 C>секунды по незагруженной 100Мбит-сети).
Очень смешно. Все 5000x5000 надо одновременно отобразить? :-O
C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в C>них).
Значит это ещё не выход.
>> Так что не надо предрассудков. Проверьте сначала. Я вот кроме графики >> уровня 3D-стрелялок ничего представить не могу, что требовало бы >> связывать в один контекст логику и отображение. C>У меня идет обработка данных с измерительных устройств.
И у меня идёт. И что?
>> А если таки потребуется — я всё равно unix way применю. C>Ага. И изображать данные будете через пайпы. А управлять вращениями C>частей — задавая координаты кватернионов из командной строки.
Никаких пайпов.
>> Только внутри одного контекста. Не знаете, как? C>Через пайпы? Так это много ума не надо.
Я же сказал — Внутри. Одного. Контекста. Какие пайпы, блин! Это ОДИН ПРОЦЕСС. С общей памятью. Физически. А логически — две отдельные программы, обменивающиеся сообщениями.
Здравствуйте, Cyberax, Вы писали:
C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3 C>секунды по незагруженной 100Мбит-сети).
C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в C>них).
А на какой технике и сколько времени это дело обсчитывается? Если не секрет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>> Как представлю себе десериализацию из тестового потока в каком-нить С++ C>Сейчас вам скажут, что надо использовать S-выражения, которые еще и C>выполняться сами могут
Я, в принципе, не против Unix-way. Просто при росте сложности системы, имхо, что-то вроде COM'a начинает рулить намного сильнее, чем попытка связать воедино с десяток разрозненных программ. С другой стороны, десяток разрозненных программ удобны для автоматизации. Сбацал скрипт, их связывающий, повесил на cron и отдыхаешь.
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Cyberax, Вы писали:
C>Мальчик, файл и VFS в юниксах — это классический пример объектного C>дизайна. VFS — так это вообще textbook example для полиморфизма.
Дедушка, эта ваша фраза — типичный пример так называемого передёргивания, каковое является частным случаем так называемой демагогии.
>> И реализован он будет через временный файл. Оно нам надо? C>Нет. Реализован он может быть как угодно. Лично делал IStream поверх C>DB-блоба.
Вы специально тормозите? Так это уже не смешно. Какая на фиг разница, файл, блоб, хреноб — главное, что под это нужно физическое пространство. Следовательно — избегать надо подобных приколов, за исключением самых крайних случаев.
Kolhoz wrote: > C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3 > C>секунды по незагруженной 100Мбит-сети). > Очень смешно. Все 5000x5000 надо одновременно отобразить? :-O
На принтере — вполне себе нормально.
Для отображения на экране модель упрощается, но вынести его на сервер
нельзя. Так как при приближении модели упрощенные детали должны проявляться.
> C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в > C>них). > Значит это ещё не выход.
То есть?
> C>У меня идет обработка данных с измерительных устройств. > И у меня идёт. И что?
И ничего. Я объяснил откуда у меня трехмерные данные.
>> > Только внутри одного контекста. Не знаете, как? > C>Через пайпы? Так это много ума не надо. > Я же сказал — Внутри. Одного. Контекста. Какие пайпы, блин! Это ОДИН > ПРОЦЕСС. С общей памятью. Физически. А логически — две отдельные > программы, обменивающиеся сообщениями.
А нафига???
Кстати, трехмерный отображатель, обработчик данных и измеритель у меня —
разные подсистемы (сделанные на COM). Причем конфигурация всего может
управляться из любого COM-клиента, а в само приложение встроен VBA (как
в Word/Excel).
eao197 wrote: > C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3 > C>секунды по незагруженной 100Мбит-сети). > C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в > C>них). > А на какой технике и сколько времени это дело обсчитывается? Если не секрет.
Обычные современные PC. Хотя 32-бит уже хватает с трудом — часто
переполняется адресное пространство.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>>>Извините, .NET — это международный стандарт, который с Windows никак не связан.
Точка-нет алеко ещё не то что до международного стандарта, но и до отраслевого тянуться и тянуться нужно.
POSIX — семейство международных стандартов на Си API, утилиты и средсва функционирования UNIX-подобных систем. Это уже действительно международный стандарт, подтверждённый ISO и IEC.
А что там точка-нэт? Да через пять лет о ней никто и вспоминать не будет. Ну было, что-то вроде переносимого OLE.
iZEN>>Шарашка под названием ECMA, которую спонсируют Intel, Apple и Microsoft, не такая уж и иеждународная организация по стандартизации. АХ>Ага, конечно . см. здесь. АХ>Цитата: АХ>
АХ>ECMA was founded in 1961 to standardise computer systems in Europe.
АХ>В 1961 ни Intel, ни Apple, ни Microsoft, ни Sun не существовало. Только IBM был.
И что? Сейчас три вышеперечисленные мною компании в открытую спонсируют ECMA, не говоря уже о мелких конторках. Но почему-то IBM и Sun не спешат присоединяться.
Mamut wrote: > Я, в принципе, не против Unix-way. Просто при росте сложности системы, > имхо, что-то вроде COM'a начинает рулить намного сильнее, чем попытка > связать воедино с десяток разрозненных программ. С другой стороны, > десяток разрозненных программ удобны для автоматизации. Сбацал скрипт, > их связывающий, повесил на cron и отдыхаешь.
Ну так об этом я и говорил уже в куче сообщений
В ответ обычно примерно такое:
Опять 5*5... Эта компонентность не более мощная. Она более частная.
Она реализуется тривиально поверх примитивов unix way, а вот unix way
поверх объектной компонентной модели — нет. Не сравнивайте даже общее
решение с частным!
Kolhoz wrote: > C>Мальчик, файл и VFS в юниксах — это классический пример объектного > C>дизайна. VFS — так это вообще textbook example для полиморфизма. > Дедушка, эта ваша фраза — типичный пример так называемого > передёргивания, каковое является частным случаем так называемой демагогии.
А по сути ответить нет ничего?
У меня сейчас в другой программе (построитель сценариев измерения)
используется самодельный VFS, например. На нем даже grep уже есть. То
есть я банально могу построить аналог юниксовой системы с помощью ООП, а
вот наоборот — не получится.
> C>Нет. Реализован он может быть как угодно. Лично делал IStream поверх > C>DB-блоба. > Вы специально тормозите? Так это уже не смешно. Какая на фиг разница, > файл, блоб, хреноб — главное, что под это нужно физическое пространство.
Его не нужно на локальном компьютере. Блоб себе лежит где-то в базе, а
на мой компьютер приходят страницы по требованию.
А вот вам пришлось бы создавать временные файлы. Кстати, можно и
вычисляемый IStream сделать.
Здравствуйте, Cyberax, Вы писали:
>> C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3 >> C>секунды по незагруженной 100Мбит-сети). >> C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в >> C>них). >> А на какой технике и сколько времени это дело обсчитывается? Если не секрет. C>Обычные современные PC. Хотя 32-бит уже хватает с трудом — часто C>переполняется адресное пространство.
Ну а все-таки сколько времени занимает расчет. Подозреваю, что расчет и запись 0.5Gb данных в ОП будет занимать не меньше нескольких секунд.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > C>Обычные современные PC. Хотя 32-бит уже хватает с трудом — часто > C>переполняется адресное пространство. > Ну а все-таки сколько времени занимает расчет. Подозреваю, что расчет и > запись 0.5Gb данных в ОП будет занимать не меньше нескольких секунд.
Изначальный рассчет может занимать достаточно долго, до минут на очень
сложных примерах. На реальных примерах — порядка десяти секунд.
Потом уже используются построенные индексы для дальнейших операций, и
все работает очень быстро.
Здравствуйте, Mamut, Вы писали:
M>Я, в принципе, не против Unix-way. Просто при росте сложности системы, имхо, что-то вроде COM'a начинает рулить намного сильнее, чем попытка связать воедино с десяток разрозненных программ. С другой стороны, десяток разрозненных программ удобны для автоматизации. Сбацал скрипт, их связывающий, повесил на cron и отдыхаешь.
Вот вот, я и имел ввиду, точнее я этого еще не говорил Просто хотелось узнать, есть ли такое в линуксе нечто подобное. Просто в данный момент работаю над крупным проектом и тут все завязано под КОМ технологию, и стало интересно, а можно ли в линуксе как то тоже применить компонентную модель. Т.к. дома стоит Сюся и я в свободное от работы время пытаюсь писать под линукс (честно говоря плохо получается ), но дальше хелоу ворлдов не доходило.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Всем Ну, вернее, отсылка самого факса, конечно, практически равнозначна. А вот уже считывание факсовых событий, пробег по папкам в винфаксе и вытягивание из них сообщений может оказаться для Unix-way геморроем (пишу по памяти):
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"
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Kolhoz wrote: > C>И? Это означает, что если что-то не делать, чтобы оно работало совместно > C>- то оно совместно работать не будет. > Нет. Это означает — сначала сделай хороший двигатель, а потом думай, > какой кожей обивать кресла и какого цвета будет стрелка на спидометре.
Ага, сначала сделать крутой двигатель, а потом обнаружить, что ему нужен
бензин Аи-99.
> C>OLE на интерфейс вааще пофиг. Он работает с прямоугольниками рисования и > C>объектами данных. Как их интерпретирует приложение — личное дело самого > C>приложения. > Вот вот. Это и есть — ущербный и ограниченный подход, который не > позволяет делать даже самые простейшие вещи (см. пример задачи несколько > ранее).
Пайпы могут наливать мне кофе? Отсойная вещь! Они даже не могут код на
С++ компилировать!
OLE — это способ связывания разных компонентов и их визуального
отображения. Что делают эти компоненты внутри — OLE не волнует.
Называется это умным словом — "инкапсюляция".
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.
Ну-ну. От вас технических возражений по сути и не было.
Здравствуйте, Kolhoz, Вы писали:
DK>>Дело в том, что распростанённость этого чуда весьма низка... K> Ваша заява никак не вписывается в логику предыдущего вашего же утверждения. K> Знаете, есть такой пренеприятнейший тип людей, кто не способен признавать свои ошибки и всячески старается их замазать и заболтать. Так, к сведению.
Ну, что ж вы так агрессивно настроены?
Я про гегемонию МС говорил, за которой обывателю не видны ни линУксы, ни цыгВины, ни прочие проблески разума среди пошлой коммерции.
DK>>Отсюда мораль, выживает тот, кто выживает (кого-то). (тобишь мелкомягкие) K> А что, с X-Window что-то случилось? Вроде бы очень даже неплохо выживает. Что бы там всякие малограмотные не вещали.
У простого юзера винды НЕТ X-Window, в отличие от WinAPI, что бы там офигевшие и зазнавшиеся линуксоиды не говорили
Все мы там будем
Здравствуйте, 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 следует избегать). Но без фанатизма.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, iZEN, Вы писали:
ZEN>POSIX — семейство международных стандартов на Си API, утилиты и средсва функционирования UNIX-подобных систем. Это уже действительно международный стандарт, подтверждённый ISO и IEC.
И при чем тут компонентный подход?
Это вообще offtopic.
Windows, кстати, поддерживает POSIX.1 и пресловутые pipes: здесь.
ZEN>А что там точка-нэт? Да через пять лет о ней никто и вспоминать не будет. Ну было, что-то вроде переносимого OLE.
Мне кажется, что ты глубоко заблуждаешься .
Еще посмотрим, когда Mono доделают как он на Unix системах развернется .
M>ЗЫ. WinFax'овые объекты тоже весьма Unix-way. Во-первых, возвращают только BSTR. Во вторых, функции GetMessageTime и GetMessageDate возвращают строки locale-aware. То есть, на US locale они возвращают, соответственно, "06/22/2006" и "08:01 РМ". А на RU locale — "22.06.2006" и "20:01"
Ха, так мы тут на ту же штуку напоролись, только с другой стороны в .NET.
В файле значения с плавающей точкой записаны как обычно через '.', а "умные" функции .NET использующие местную локаль, которая у меня русская, решили что они должны быть через ','.
В результате в процессе парсинга строки System.Convert.ToDouble вываливался с exception.
K> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным! Да все в точности наоборот!
Передайте от одного компонента другому имя файла и будет вам полнейший Unix way.
Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).
Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.
Здравствуйте, Андрей Хропов, Вы писали:
АХ> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы). АХ> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.
Что?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 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 вырезать нужный фрагмент и вставить его как битмап. Собственно на этом так называемые "безграничные возможности" буфера обмена и заканчиваются.
Может я чего-то не понимаю, но меня от подобной халтуры тошнит. Как вся эта помойка может нравиться, я тем более не понимаю. Ребята! Брынза не бывает зеленого цвета — это вас кто-то обманул.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Мне кажется, что ты глубоко заблуждаешься . АХ>Еще посмотрим, когда Mono доделают как он на Unix системах развернется .
Не доделают его — это нереально.
Он обречён на отставание.
Посмотри с какой скоростью плодятся всякие C# 3.0, LINQ, ADO.NET 3, WCF, WPF и прочие buzzwords.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Андрей Хропов, Вы писали:
АХ>> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы). АХ>> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.
E>Что?
Ну нормальные компонентные модели вроде COM, CORBA, Java EE, .NET, которые поддерживают сообщения, обмен типизированными данными и т.п.
Зачем сериализовывать/десериализовывать в файл данные которые как параметр функции можно передать?
Я не спорю, Unix way через пайпы и фильтры — это неплохо. Но у него есть существенные ограничения, о которые здесь уже говорилось. Современные компонентные модели более универсальны.
Вот, скажем как вы подсистемы игры будете писать с помощью Unix way?
Здравствуйте, Cyberax, Вы писали:
>> C>Мальчик, файл и VFS в юниксах — это классический пример объектного >> C>дизайна. VFS — так это вообще textbook example для полиморфизма. >> Дедушка, эта ваша фраза — типичный пример так называемого >> передёргивания, каковое является частным случаем так называемой демагогии. C>А по сути ответить нет ничего?
Куда уж более по сути. Где вы тут объектщину углядели? По мне так чистейший KISS и unix way.
C>У меня сейчас в другой программе (построитель сценариев измерения) C>используется самодельный VFS, например. На нем даже grep уже есть. То C>есть я банально могу построить аналог юниксовой системы с помощью ООП, а C>вот наоборот — не получится.
Так вот и не получится? За базар отвечать готовы?
C>Его не нужно на локальном компьютере. Блоб себе лежит где-то в базе, а C>на мой компьютер приходят страницы по требованию.
А мне без разницы. Главное, что ресурс потреблятся зря.
C>А вот вам пришлось бы создавать временные файлы. Кстати, можно и C>вычисляемый IStream сделать.
Не пришлось бы. С тем же успехом и я мог бы всунуть прослойку, которая реализовывалась бы как blob в базе.
Здравствуйте, McSeem2, Вы писали:
MS>Может я чего-то не понимаю, но меня от подобной халтуры тошнит. Как вся эта помойка может нравиться, я тем более не понимаю. Ребята! Брынза не бывает зеленого цвета — это вас кто-то обманул.
Надо признать, что реализация у МС хромает. Но давайте рассмотрим опять этот злосчастный .NET, у которой тоже реализация подхрамывает Для меня важна философия, архитектура, документация, перспективы итд, а баги это не самое главное.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Kolhoz, Вы писали:
K>> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным! АХ> Да все в точности наоборот! АХ> Передайте от одного компонента другому имя файла и будет вам полнейший Unix way.
Какого файла? А если я туда netcat вставил? Или ssh?
АХ> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).
Нет.
Дао Unix way:
— на каждую функциональную единицу — отдельный компонент
— к компоненту предъявляются требования:
* возможность как программного так и интерактивного задействования всех его функций.
* корректное сообщение о любых исключительных ситуациях
* наличие максимально простого для программной обработки протокола передачи как потребляемых, так и производимых компонентом данных.
— в системе из нескольких компонент между любыми двумя компонентами должна быть возможность встроить третий
Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао.
АХ> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.
Что же? Объектно-ориентированную религию не предлагать, тошно-с.
Здравствуйте, Андрей Хропов, Вы писали:
E>>Что? АХ>Ну нормальные компонентные модели вроде COM, CORBA, Java EE, .NET, которые поддерживают сообщения, обмен типизированными данными и т.п.
COM уже масштабируется на сеть (про DCOM знаю, хорошо что это убожество умерло)?
CORBA — это просто один из малость извращенческих, но всего лишь RPC. Как и .net remoting. Это не компонентная модель и тем более не идеология. Внутри unix way применять можно, худо-бедно, а отдельно — лучше не стоит.
АХ>Зачем сериализовывать/десериализовывать в файл данные которые как параметр функции можно передать?
Затем, что может потребоваться встроить между отправителем и получателем ещё кого-то, кто эти данные перехватит и обработает. Например, по сети отправит. Или мультиплексирует на десяток других получателей. Или просто залоггирует с целью дебага.
АХ>Я не спорю, Unix way через пайпы и фильтры — это неплохо. Но у него есть существенные ограничения, о которые здесь уже говорилось. Современные компонентные модели более универсальны.
Вот и попробуйте это доказать. И что ограничения так уж существенны, и что эти мифические, так и не названные "современные компонентные модели" более универсальны (это уж и вовсе тривиально доказываться — свести семантику этих моделей к семантике unix way, тем самым показав его частность).
АХ>Вот, скажем как вы подсистемы игры будете писать с помощью Unix way?
Здравствуйте, Cyberax, Вы писали:
>> Нет. Это означает — сначала сделай хороший двигатель, а потом думай, >> какой кожей обивать кресла и какого цвета будет стрелка на спидометре. C>Ага, сначала сделать крутой двигатель, а потом обнаружить, что ему нужен C>бензин Аи-99.
Опять за неимением аргументов начинаем передёргивать?
Моя аналогия предельно ясна — нельзя плясать от GUI, от морды. Бензин — технологическое требование.
>> Вот вот. Это и есть — ущербный и ограниченный подход, который не >> позволяет делать даже самые простейшие вещи (см. пример задачи несколько >> ранее). C>Пайпы могут наливать мне кофе? Отсойная вещь! Они даже не могут код на C>С++ компилировать!
Как не могут? Очень даже могут. Была в одной конторке кофеварка с управлением по USB, народ там юниксовых утилит к ней понаписал. Весело было...
C>OLE — это способ связывания разных компонентов и их визуального C>отображения. Что делают эти компоненты внутри — OLE не волнует. C>Называется это умным словом — "инкапсюляция".
Это называется так, что в этой роли OLE — ну ни разу не компонентная модель, а просто идиотский (за неимением нормальных) способ встроить окно одного приложения в другое. В рамках unix way это делается чище и гибче.
Здравствуйте, Cyberax, Вы писали:
>> Очень смешно. Все 5000x5000 надо одновременно отобразить? :-O C>На принтере — вполне себе нормально.
Вы бы хоть иногда поток сознания через фильтр какой пропускали, а?
Ну при чём тут принтер?!?
C>Для отображения на экране модель упрощается, но вынести его на сервер C>нельзя. Так как при приближении модели упрощенные детали должны проявляться.
И почему вынести нельзя? Очень даже можно. И протокол с обратной связью сделать. У меня во всех системах визуализации оно так и устроено.
>> C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в >> C>них). >> Значит это ещё не выход. C>То есть?
То есть, нужен ещё один уровень обработки.
>> Я же сказал — Внутри. Одного. Контекста. Какие пайпы, блин! Это ОДИН >> ПРОЦЕСС. С общей памятью. Физически. А логически — две отдельные >> программы, обменивающиеся сообщениями. C>А нафига???
Нам же нужна компонентная модель, не так ли? С минимальным оверхедом, когда дело доходит до всякоразного HPC, но со всеми плюшками от компонентности для разработчиков — и code reuse, и чёткое разграничение функциональных элементов, и масштабируемость, понадобится — легко можно разорвать компоненты и разбросать по кластеру — в коде самих компонентов менять ничего не придётся.
C>Кстати, трехмерный отображатель, обработчик данных и измеритель у меня — C>разные подсистемы (сделанные на COM). Причем конфигурация всего может C>управляться из любого COM-клиента, а в само приложение встроен VBA (как C>в Word/Excel).
Ну и как, слабО теперь эти отдельные компоненты растащить на разные узлы кластера? Или вставить дополнительную обработку между ними, не трогая совсем никак их код?
Здравствуйте, Cyberax, Вы писали:
>> В .NET из компонентностей есть только довольно примитивные формы RPC и >> сериализации и интерфейс ко всё тому же OLE. Ничего чистого и тем более >> наглядного не прослеживается — нет даже общей идеологии. C>Назовите НЕпримитивные формы RPC.
Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело.
У пользователей Схемы или Тикла получается лучше.
C>Ну и OLE к .NET не имеет никакого отношения. Может не стоит показывать C>своего незнания в обоих предметах?
Я же сказал — в .NET есть интерфейс к OLE. Скажешь, нет? :-O
>> Вы поработайте для сравнения в команде, где весь документооборот на вордах, >> и в команде, где с одной стороны docbook, а с другой — >> bugzilla+cvszilla. Поймёте, почему вторая команда будет свысока смотреть >> на первую. C>Пробовал. После $#TY$OIU# с docbook в итоге перешли на Word.
Хреновенько пробовали, значит. Я пока не встречал ни одной не-ламерской конторы, где использовали бы Word, и множество крутых, пользующихся docbook или доморощенными аналогами.
C>И уж системы багтрекинга и SCM к формату документов не имеют никакого C>отношения.
Имеет, имеет. Они должны идеально интегрироваться в документооборот. Или вы всё ручками делаете? Представляю, какой кошмар и бардак у вас творится. Одна только попытка засунуть вордовый документ в cvs, думаю, будет тем ещё цирком. А уж обеспечить гарантированную целостность проектной документации, системы автоматического тестирования, системы багтрекинга и документации к коду, пользуясь вордом — это задача века, за её решение надо конный памятник в масштабе 1:50 ставить. Из чистого золота. Прижизненный.
>> Ламер — не тот, кто пользуется виндовсом (я вот почти только под виндовс >> и писал всегда), а тот, кто не желает думать своей головой и ведётся на >> дешевый appeal to authority. C>Ага. Всякой чепухе про Unix way, например.
Я, в отличии от некоторых, чепуху доказываю, а не ссылаюсь на чьи либо авторитетные мнения.
C>Ну-ну. От вас технических возражений по сути и не было.
Как не было? Было. И все были успешно проигнорированы.
Здравствуйте, DJ KARIES, Вы писали:
DK>Ну, что ж вы так агрессивно настроены? DK>Я про гегемонию МС говорил, за которой обывателю не видны ни линУксы, ни цыгВины, ни прочие проблески разума среди пошлой коммерции.
Любой независимый объективный семантический анализ вашего текста покажет совершенно обратное — вы говорили, что технологии unix way физически не интегрируются в Windows. Что не есть истина.
DK>У простого юзера винды НЕТ X-Window, в отличие от WinAPI, что бы там офигевшие и зазнавшиеся линуксоиды не говорили
И кого волнуют простые юзеры винды? Мы про них тут вообще не говорим.
Здравствуйте, Kolhoz, Вы писали:
K> Успокойтесь. Всё работает очень быстро. Посмотрите, например, на X11, где вся графика гоняется через unix domain socket, если локально, и через, например, tcp, если удалённо. И ничего, работает.
То-то я смотрю XPutImage так тормозит. А без него качественно отобразить векторную графику — ну никак не получается (только не надо говорить, что это X-сервер умеет делать — не умеет он ничего). Вот и получается, что без костылей типа MIT-SMH — никуда.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Kisloid, Вы писали:
K>Надо признать, что реализация у МС хромает. Но давайте рассмотрим опять этот злосчастный .NET, у которой тоже реализация подхрамывает Для меня важна философия, архитектура, документация, перспективы итд, а баги это не самое главное.
Я уже приводил свое видение рекламного слогана для дот-нет:
Аналогично для MS Office:
Теоретически, безусловно все может быть, даже то, чего быть не может. На практике — число глюков в пересчете на условную единицу функциональности неуклонно растет.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, EvilChild, Вы писали:
EC>Не доделают его — это нереально. EC>Он обречён на отставание. EC>Посмотри с какой скоростью плодятся всякие C# 3.0, LINQ, ADO.NET 3, WCF, WPF и прочие buzzwords.
Мне Мигель говорил что C# 2.0 поддерживается на 90%, причем 10% это баги Это было давно, примерно полгода назад.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, McSeem2, Вы писали:
MS>Теоретически, безусловно все может быть, даже то, чего быть не может. На практике — число глюков в пересчете на условную единицу функциональности неуклонно растет.
Ну не скажи, вспомни хотя бы Win95 и сравни с XP, как небо и земля. Win 95 а может даже и Win 3.x дало верное направление развития, дало начало.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, iZEN, Вы писали:
VD>>Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП. ZEN>По последним новостям проекта Mono до сих пор не решены проблемы работы "компонентов" WinForms.
Источкник новостей, плиз. Или так уж честно и говори "по слухам".
С компонентным подходм в Моно проблем нет. Тот же компилятор Немерле использует компонентный подход для динамической подгрузки макросов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kolhoz, Вы писали:
K>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Здравствуйте, Kolhoz, Вы писали:
K>>> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным! АХ>> Да все в точности наоборот! АХ>> Передайте от одного компонента другому имя файла и будет вам полнейший Unix way.
K> Какого файла? А если я туда netcat вставил? Или ssh?
И? В чем проблема?
Передайте имя файла netcatу, а он дальше передаст.
то что вы пишете в Unix как
"ls | more"
можно записать как (условно)
"File result = more.Process( ls.Process(input) )".
more и ls некие компоненты.
Чуть больше слов, но суть та же.
АХ>> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).
K> Нет.
K> Дао Unix way: K>- на каждую функциональную единицу — отдельный компонент
Правильно — в любой компонентной системе так.
K>- к компоненту предъявляются требования: K> * возможность как программного так и интерактивного задействования всех его функций.
Правильно. Так как вы там интерактивность в Unix way обеспечиваете?
K> * корректное сообщение о любых исключительных ситуациях
Сообщение мало. Надо еще данные не убить по возможности.
Без поддержки исключений обработка ошибок — это геморрой жуткий.
Я уж не говорю про RAII. А это предполагает ОО.
K> * наличие максимально простого для программной обработки протокола передачи как потребляемых, так и производимых компонентом данных. K>- в системе из нескольких компонент между любыми двумя компонентами должна быть возможность встроить третий
Эээ. Вот тут мне видится фундаментальный изъян.
Дело в том что для того чтобы вставить на вход одного компонента выхлоп из другого нужно чтобы у них были совместимы интерфейсы, т.е. передаваемая информация была в одном формате,
в unix way используется наименьший общий знаменатель — простой текст.
Часто программы работают все же не с простым текстом, а со структурированными данными
(простейшие утилиты вроде grep не берем в расчет), поэтому имеем оверхед на сериализацию/десериализацию.
А любой компонент в середину все равно нельзя, поскольку обработка разной информации требует разных компонентов (пример с закодированными символами в HTML уже приводился, так же можно сказать что с ASCII и Unicode надо работать по-разному и т.п.).
Вот LaTeX — это Unix way?
в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?
K> Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао.
Имеют свои плюсы, но не универсальны.
АХ>> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.
K> Что же? Объектно-ориентированную религию не предлагать, тошно-с.
Глупости говорите. ОО давно уже само-собой. Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .
Здравствуйте, Андрей Хропов, Вы писали:
K>>- к компоненту предъявляются требования: K>> * возможность как программного так и интерактивного задействования всех его функций. АХ>Правильно. Так как вы там интерактивность в Unix way обеспечиваете?
ну... собственно консолью и обеспечиваем, нет?
find /usr/src/linux -name "*.c" -exec grep -H "fuck" {} \; | wc -l
чем не интерактивность?
с другой стороны. что для этого предлагает КОМ? таки да, компонентность есть, но... а где интерактивность?
K>> * корректное сообщение о любых исключительных ситуациях АХ>Сообщение мало. Надо еще данные не убить по возможности. АХ>Без поддержки исключений обработка ошибок — это геморрой жуткий.
вот этого я не понял. если софтина приняла на вход что-то и умерла, то она об этом корректно сообщила. что не так?
АХ> А любой компонент в середину все равно нельзя, поскольку обработка разной информации требует разных компонентов (пример с закодированными символами в HTML уже приводился, так же можно сказать что с ASCII и Unicode надо работать по-разному и т.п.).
логично предположить что эти символы надо раскодировать. в частности (для аски и юникода) iconv. нормально? вставляется как раз между
АХ>Вот LaTeX — это Unix way? АХ>в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?
Здравствуйте, Андрей Хропов, Вы писали:
АХ>>> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы). АХ>>> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.
E>>Что? АХ>Ну нормальные компонентные модели вроде COM, CORBA, Java EE, .NET, которые поддерживают сообщения, обмен типизированными данными и т.п.
А эти нормальные компонентные модели интероперабельны между собой? Например, каким образом COM-компонент будет общаться с JavaBean-ом?
АХ>Зачем сериализовывать/десериализовывать в файл данные которые как параметр функции можно передать?
Вообще-то параметры функции все равно будут сериализоваться/десериализоваться. Вопрос в том, насколько приложение владеет процессом сериализации. И не факт, что при работе с текстовым протоколом сериализацию/десериализацию придется делать ручками -- все это может выполняться автоматическими генераторами парсеров (например. парсинг HTTP в некоторых HTTP-серверах пишется не вручную).
АХ>Я не спорю, Unix way через пайпы и фильтры — это неплохо. Но у него есть существенные ограничения, о которые здесь уже говорилось.
Давайте еще раз повторим Unix way это не только пайпы и фильты. Пайпы и фильтры -- это всего лишь самый явный пример. Unix way -- это способ проектирования приложений из отдельных частей, каждая из которых выполняет конкретную задачу и общается с другими частями по наиболее простым протоколам.
Пайпы и фильтры всего лишь самые простые механизмы. В качестве более сложного примера можно взять, например, XML-RPC или даже SOAP.
Даже упомянутая вами CORBA может быть всего лишь транспортом для больших задач. Например, при создании системы управления телефонными переговорами с использованием спецификации Parlay можно применить Unix way для декомпозиции системы на части, взаимодействующие между собой по CORBA (просто потому, что этого требует Parlay). Но каждая из частей будет выполнять всего одну конкретную подзадачу и, скорее всего, будет отдельным процессом (может быть даже на отдельной машине). Хотя более в духе Unix way была бы организация взаимодействия отдельных процессов через XML-RPC или SOAP.
Имхо, у Unix way нет предела сверху. Эта идея может масштабироваться вместе со сложностью задачи.
АХ>Современные компонентные модели более универсальны.
Да ради бога.
Я не стараюсь доказать, что Unix way лучше указанных вами компонентных технологий. Это просто другой подход.
Только вот, если бы вы смогли показать преимущества тех же CORBA, J2EE и .NET по сравнению с Unix way в области расширяемости протоколов и в области интероперабильности, то я с удовольствием бы почитал такое сравнение.
АХ>Вот, скажем как вы подсистемы игры будете писать с помощью Unix way?
А какие игры? 3D shutter, RPG, Real-Time Strategy?
Если я не ошибаюсь, то в 3D shutter-ах, допускающих сетевую игру, как раз Unix way и использутся (т.е. есть сервер, который отслеживает всех игроков, а есть клиенты, которые отображают происходящее игрокам).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Kisloid, Вы писали:
K>Здравствуйте, McSeem2, Вы писали:
MS>>Теоретически, безусловно все может быть, даже то, чего быть не может. На практике — число глюков в пересчете на условную единицу функциональности неуклонно растет.
K>Ну не скажи, вспомни хотя бы Win95 и сравни с XP, как небо и земля. Win 95 а может даже и Win 3.x дало верное направление развития, дало начало.
Win2K гораздо устойчивее чем WinXP. Вообще помоему WinXP по устойчивости только чуть лучше чем Win98SE.
K> Моя аналогия предельно ясна — нельзя плясать от GUI, от морды.
Можно. Плясание именно от морды — это наипервейшее требование разработки Web-приложений. Потому что никого не волнует, как оно там, на сервере, творится. Главное — чтобы результаты были в доступном виде на экране. Но это — частный случай.
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Cyberax, Вы писали:
>> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, >> преимущественно под Windows, и ну ни разу не приходилось применять их, >> вендовый стиль мышления. К чему бы это? C>Ну так покажите эти GUI. И их пользователей. Какие проблемы?
Я так понимаю, что образец GUI для подражания в количестве "много" нам не покажут?
Здравствуйте, VladD2, Вы писали:
iZEN>>По последним новостям проекта Mono до сих пор не решены проблемы работы "компонентов" WinForms. VD>Источкник новостей, плиз. Или так уж честно и говори "по слухам".
Да у них на сайте чёрным по белому написано. Не могут решить, какую версию библиотеки GTK использовать и
использовать ли её вообще для реализации WinForms. Месяц назад смотрел специально.
VD>>>Под Линукс прекрасно работают Ява и Моно. Этого более чем достаточно. Потом практически любой скриптовый язык решает задачи в том числе аналогичные КОП.
VD>С компонентным подходм в Моно проблем нет. Тот же компилятор Немерле использует компонентный подход для динамической подгрузки макросов.
Про языки будем отдельно говорить, так и Delphi/Kylix можно подцепить.
В теме рассматривается проблема: а так ли хорошо реализован КОП в Linux или не очень хорошо.
Пока все склоняются в сторону того, что КОП в Linux реализован иначе, не как в Windows, но в любом случае использование подхода КОП как в Windows тоже не возбраняется.
В Windows, например, очень трудно использовать подход UNIX просто из-за того, что пользователи (программисты и просто пользователи) зашорены идеологией виндовс и не способны мыслить иначе, чем кнопочками, диалогами и командой "Выполнить".
Здравствуйте, Kolhoz, Вы писали:
K>Здравствуйте, Cyberax, Вы писали:
>>> В .NET из компонентностей есть только довольно примитивные формы RPC и >>> сериализации и интерфейс ко всё тому же OLE. Ничего чистого и тем более >>> наглядного не прослеживается — нет даже общей идеологии. C>>Назовите НЕпримитивные формы RPC.
K> Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело. K> У пользователей Схемы или Тикла получается лучше.
Н-да? EJB построен вокруг Объектного RPC — синхронного RMI и асинхронного JMS. Интересно, если они "развлекаются", то как же получается делать кластеры, работающие 24x7 и 24x365 в промышленных системах?
Здравствуйте, 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.
Нажал кнопку "Установить" — все установилось , "выполнить" — выпонилось
и не люблю по запутанным мануалам изучать значения флагов в командной строке.
Пусть простые задачи будут простыми.
Здравствуйте, FR, Вы писали:
K>>Ну не скажи, вспомни хотя бы Win95 и сравни с XP, как небо и земля. Win 95 а может даже и Win 3.x дало верное направление развития, дало начало.
FR>Win2K гораздо устойчивее чем WinXP. Вообще помоему WinXP по устойчивости только чуть лучше чем Win98SE.
Не знаю, у меня никаких проблем с WinXP.
Да она и не может быть хуже чем Win2K ибо там ядро оттуда же растет.
Линейка Win9x закончилась на WinME. Все что дальше — отростки NT.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, FR, Вы писали:
K>>>Ну не скажи, вспомни хотя бы Win95 и сравни с XP, как небо и земля. Win 95 а может даже и Win 3.x дало верное направление развития, дало начало.
FR>>Win2K гораздо устойчивее чем WinXP. Вообще помоему WinXP по устойчивости только чуть лучше чем Win98SE. АХ>Не знаю, у меня никаких проблем с WinXP. АХ>Да она и не может быть хуже чем Win2K ибо там ядро оттуда же растет.
По устойчивости может и есть.
У меня на одном и том же железе win2k практически ни разу ни падал, XP падает примерно раз в месяц — два.
АХ>Линейка Win9x закончилась на WinME. Все что дальше — отростки NT.
Я про что и говорю NT начал портится скоро до уровня 9X дойдет. Вообще я уже побаиваюсь за висту.
Здравствуйте, FR, Вы писали:
FR> FR>Я про что и говорю NT начал портится скоро до уровня 9X дойдет. Вообще я уже побаиваюсь за висту.
Да я думаю ядро там не трогают. Вроде рюшечки eye candy только навешивают (Avalonы там всякие) .
eao197 wrote: > А эти нормальные компонентные модели интероперабельны между собой? > Например, каким образом COM-компонент будет общаться с JavaBean-ом?
Может. См. http://danadler.com/jacob
> Вообще-то параметры функции все равно будут > сериализоваться/десериализоваться. Вопрос в том, насколько приложение > владеет процессом сериализации. И не факт, что при работе с текстовым > протоколом сериализацию/десериализацию придется делать ручками -- все > это может выполняться автоматическими генераторами парсеров (например. > парсинг HTTP в некоторых HTTP-серверах пишется не вручную).
С другой стороны, с COM/.NET сериализацию делать вообще НЕ надо. Можно
сразу передавать графы объектов.
> Давайте еще раз повторим Unix way это не только пайпы и фильты. Пайпы и > фильтры -- это всего лишь самый явный пример. Unix way -- это способ > проектирования приложений из отдельных частей, каждая из которых > выполняет конкретную задачу и общается с другими частями по наиболее > простым протоколам.
Нет уж. Способ проектирования приложения из частей — это называется
"здравый смысл"
Unix way — это именно приложения, интероперирующие через
пайпы/файлы/командную строку.
> Имхо, у Unix way нет предела сверху. Эта идея может масштабироваться > вместе со сложностью задачи.
Если под "unix way" понимать создание модульных приложений — то
естественно. Причем Unix'ом оно не ограничивается
> Только вот, если бы вы смогли показать преимущества тех же CORBA, J2EE и > .NET по сравнению с Unix way в области расширяемости протоколов и в > области интероперабильности, то я с удовольствием бы почитал такое > сравнение.
Хорошая идея для статьи, попробую написать.
> А какие игры? 3D shutter, RPG, Real-Time Strategy? > Если я не ошибаюсь, то в 3D shutter-ах, допускающих сетевую игру, как > раз Unix way и использутся (т.е. есть сервер, который отслеживает всех > игроков, а есть клиенты, которые отображают происходящее игрокам).
Ну такими темпами любое клиент-серверное приложение будет Unix-way'ем.
Anton Batenev wrote: > C>Ну так покажите эти GUI. И их пользователей. Какие проблемы? > Я так понимаю, что образец GUI для подражания в количестве "много" нам > не покажут?
Из своего я могу только скриншоты наделать, а по ним не очень понятно
что и как работает.
Здравствуйте, Андрей Хропов, Вы писали:
K>> Какого файла? А если я туда netcat вставил? Или ssh? АХ>И? В чем проблема? АХ>Передайте имя файла netcatу, а он дальше передаст.
Интересно, как бы вы предложили удалять гланды. Я, кажется, заранее догадываюсь.
АХ>то что вы пишете в Unix как АХ>"ls | more" АХ>можно записать как (условно) АХ>"File result = more.Process( ls.Process(input) )". АХ>more и ls некие компоненты.
АХ>Чуть больше слов, но суть та же.
Не та же. Я не могу между more и ls вставить в этой модели ничего (sort, например).
K>> Дао Unix way: K>>- на каждую функциональную единицу — отдельный компонент АХ>Правильно — в любой компонентной системе так.
Не в любой. В объектных моделях для этого функциональная единица должна совпадать с объектом. А это не всегда возможно. Скорее, это почти никогда не возможно — объектная иерархия редко совпадает с семантической.
K>>- к компоненту предъявляются требования: K>> * возможность как программного так и интерактивного задействования всех его функций. АХ>Правильно. Так как вы там интерактивность в Unix way обеспечиваете?
Не понял вопроса. Легко и непринуждённо обеспечиваем.
K>> * корректное сообщение о любых исключительных ситуациях АХ>Сообщение мало. Надо еще данные не убить по возможности. АХ>Без поддержки исключений обработка ошибок — это геморрой жуткий. АХ>Я уж не говорю про RAII. А это предполагает ОО.
ОО тут совершенно не при делах...
АХ>Эээ. Вот тут мне видится фундаментальный изъян. АХ>Дело в том что для того чтобы вставить на вход одного компонента выхлоп из другого нужно чтобы у них были совместимы интерфейсы, т.е. передаваемая информация была в одном формате, АХ>в unix way используется наименьший общий знаменатель — простой текст.
Не обязательно. Не нужна совместимость, на самом деле.
АХ>Часто программы работают все же не с простым текстом, а со структурированными данными АХ>(простейшие утилиты вроде grep не берем в расчет), поэтому имеем оверхед на сериализацию/десериализацию.
Ну так кто просит использовать простой текст там, где не требуется?
АХ>Вот LaTeX — это Unix way? АХ>в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?
Могу, и как правило вставляю (psnup, ps2ps, мелкие самописные пошкрип-фильтры). Смысла много — postscript обрабатывать весело, легко и просто, буклетик там из него сшить, водяные знаки наложить, или ещё что, а вот pdf потом править обломно будет. Так уж лучше я поправлю ps на этом этапе.
K>> Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао. АХ>Имеют свои плюсы, но не универсальны.
Естественно. А Unix way не требует использования обязательно текстовых потоков.
K>> Что же? Объектно-ориентированную религию не предлагать, тошно-с. АХ>Глупости говорите. ОО давно уже само-собой.
К счастью, далеко не везде.
AX> Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .
Простите, какие языки? Какая функциональщина? Мне глубоко наплевать на ОО и функциональщину в языках. Наплевать и растереть. В данном случае источник мирового зла — это OOD, то есть, ОО на уровне проектирования, на компонентном уровне. Тут пока никаких языков нет и не предвидится. Как оно там внутри устроено — не колышет и не рвёт.
Здравствуйте, Mamut, Вы писали:
K>> Моя аналогия предельно ясна — нельзя плясать от GUI, от морды.
M>Можно. Плясание именно от морды — это наипервейшее требование разработки Web-приложений.
А я вот ни разу от морды не плясал. Всегда плясал от workflow, логики и структур данных. Что я делал не так? Почему всё получалось быстрее, надёжнее и эффективнее чем у всяких любителей сначала морду нарисовать, а потом думать, все ли ветки workflow покрыты и не теряется ли состояние при переходе между элементами интерфейса.
M> Потому что никого не волнует, как оно там, на сервере, творится. Главное — чтобы результаты были в доступном виде на экране. Но это — частный случай.
Здравствуйте, Anton Batenev, Вы писали:
C>>Ну так покажите эти GUI. И их пользователей. Какие проблемы?
AB>Я так понимаю, что образец GUI для подражания в количестве "много" нам не покажут?
Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview.
Я пока так и не услышал у апологетов объектной компонентности внятных идей о том, как аналогичную мощь и гибкость реализовать их смешными методами.
Здравствуйте, iZEN, Вы писали:
C>>>Назовите НЕпримитивные формы RPC.
K>> Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело. K>> У пользователей Схемы или Тикла получается лучше. ZEN>Н-да? EJB построен вокруг Объектного RPC — синхронного RMI и асинхронного JMS.
Вы, товарищ, не влезайте в тему которой не понимаете. Я про агентные протоколы говорю. А вы опять со своими примитивными RPC.
ZEN> Интересно, если они "развлекаются", то как же получается делать кластеры, работающие 24x7 и 24x365 в промышленных системах?
Это RPC и к теме не относится. Тем более что у жабистов нет ничего сравнимого с другим, гораздо более правильным примитивным RPC — MPI. Так что уж как раз кластерами хвастаться — стыдно.
Здравствуйте, Kolhoz, Вы писали:
C>>Назовите НЕпримитивные формы RPC. K> Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело.
Любой нормальный протокол RPC (RMI, DCOM, CORBA) может исопльзоваться для агентного программирования. И что дальше?
И чем именно таким развлекаются программисты на Java? SOAPом?
K> У пользователей Схемы или Тикла получается лучше.
Примеры, примеры?
C>>Ну и OLE к .NET не имеет никакого отношения. Может не стоит показывать C>>своего незнания в обоих предметах? K> Я же сказал — в .NET есть интерфейс к OLE. Скажешь, нет? :-O
Нет. Покажи мне реализацию или обертку IViewObject в стандартной библиотеке .NET, например.
Может хватит свое незнание демонстировать?
C>>И уж системы багтрекинга и SCM к формату документов не имеют никакого C>>отношения. K> Имеет, имеет. Они должны идеально интегрироваться в документооборот.
Нормальные SCM ортогональны к остальным системам. Знаменитый Unix way в вашем понимании — создание системы из независимых интероперирующих компоненов.
K> Или вы всё ручками делаете? Представляю, какой кошмар и бардак у вас творится. Одна только попытка засунуть вордовый документ в cvs, думаю, будет тем ещё цирком.
SVN и ваши волосы будут мягкими и шелковистыми.
Да, для объединения и диффов Word-документов используются скрипты: http://www.saisse.jp/svn/SandBox/Diff-Scripts/diff-doc.js и http://www.saisse.jp/svn/SandBox/Diff-Scripts/merge-doc.js ,которые прикручены к TortoiseSVN.
K> А уж обеспечить гарантированную целостность проектной документации, системы автоматического тестирования, системы багтрекинга и документации к коду, пользуясь вордом — это задача века, за её решение надо конный памятник в масштабе 1:50 ставить. Из чистого золота. Прижизненный.
Опять же, к целостности документации автотестер отношения не имеет НИКАКОГО — он работает с номерами ревизий и именами веток. Все что ему нужно знать — это куда пихать отчеты и куда слать нотификации об ошибках.
С багтрекингом и планированием немного сложнее — для планирования используется комбинация Jira/MS-Project, причем Jira мы специально дописали для совместной работы с MS-Project (Да! Работая через COM из Java!).
C>>Ага. Всякой чепухе про Unix way, например. K> Я, в отличии от некоторых, чепуху доказываю, а не ссылаюсь на чьи либо авторитетные мнения.
Покажите, где я ссылался на авторитетное мнение.
K> Как не было? Было. И все были успешно проигнорированы. K> Например, очень смешно замяли тему про ООП в GUI.
То есть? С удовольствием отвечу подробнее, если интересно.
Cyberax wrote: > С багтрекингом и планированием немного сложнее — для планирования > используется комбинация Jira/MS-Project, причем Jira мы специально > дописали для совместной работы с MS-Project (Да! Работая через COM из > Java!).
Кстати, я забыл добавить.
Все проекты у нас управляются через LDAP, так что для создания нового
проекта надо заполнить всего одну форму и будет создано:
1. Нужные почтовые ящики.
2. Структура репозитория.
3. Проекты в Jira/Confluence.
4. Участникам проекта будут предоставлены необходимые права к
репозиторию и файловому хранилищу проекта.
5. Участники будут добавлены в нужные списки рассылки.
6. И т.п.
Здравствуйте, Cyberax, Вы писали:
>> Вообще-то параметры функции все равно будут >> сериализоваться/десериализоваться. Вопрос в том, насколько приложение >> владеет процессом сериализации. И не факт, что при работе с текстовым >> протоколом сериализацию/десериализацию придется делать ручками -- все >> это может выполняться автоматическими генераторами парсеров (например. >> парсинг HTTP в некоторых HTTP-серверах пишется не вручную). C>С другой стороны, с COM/.NET сериализацию делать вообще НЕ надо. Можно C>сразу передавать графы объектов.
Которые только COM-ом и .NET-ом будут пониматься. В отличии от тех же XML-RPC или SOAP.
>> Давайте еще раз повторим Unix way это не только пайпы и фильты. Пайпы и >> фильтры -- это всего лишь самый явный пример. Unix way -- это способ >> проектирования приложений из отдельных частей, каждая из которых >> выполняет конкретную задачу и общается с другими частями по наиболее >> простым протоколам. C>Нет уж. Способ проектирования приложения из частей — это называется C>"здравый смысл"
Читая местные сообщения мне кажется, что Unix way -- это здравый смысл в чистом виде. Не даром Реймонд философию Unix характеризует всего одним принципом: KISS.
C>Unix way — это именно приложения, интероперирующие через C>пайпы/файлы/командную строку.
Еще сокеты забыл. И кстати, не знаешь, почему Реймонд приводит в качестве примера PostgreSQL, в котором процессы между собой через сокеты общаются?
>> Имхо, у Unix way нет предела сверху. Эта идея может масштабироваться >> вместе со сложностью задачи. C>Если под "unix way" понимать создание модульных приложений — то C>естественно. Причем Unix'ом оно не ограничивается
Модульном в том смысле, что каждый модуль, это отдельный процесс, взаимодействующий с другими через IPC.
C>Ну такими темпами любое клиент-серверное приложение будет Unix-way'ем.
Если оно будет допускать прозрачную смену клиента/сервера на написанные на совершенно других языках. Например, чтобы к серверу, написанному на C++ и работающему под Windows без проблем подключался Python-овый клиент из-под Solaris-а. Если так, то таки-да, будет Unix way
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Kolhoz wrote: > K>> У пользователей Схемы или Тикла получается лучше. > ZEN>Н-да? EJB построен вокруг Объектного RPC — синхронного RMI и > асинхронного JMS. > Вы, товарищ, не влезайте в тему которой не понимаете. Я про /агентные/ > протоколы говорю. А вы опять со своими примитивными RPC.
Иностранные поисковики на слова "agent protocol" выдают всякую фигню, а
родной ya.ru на "агентный/агентский протокол" выдает, в основном,
рефераты про искусственный интеллект.
Так что прошу примеры агентских протоколов и программ, их использующих.
> Это RPC и к теме не относится. Тем более что у жабистов нет ничего > сравнимого с другим, гораздо более правильным примитивным RPC — MPI. Так > что уж как раз кластерами хвастаться — стыдно.
Вообще-то у Явистов есть JMS (Java Message Service) и его адаптация для
high-performance computing.
MPI, кстати, тоже есть. Поищите по словам JavaMPI и mpiJava.
Здравствуйте, Cyberax, Вы писали:
C>>>Назовите НЕпримитивные формы RPC. K>> Любой АГЕНТНЫЙ протокол. Жабисты ими иногда развлекаются, но довольно неумело. C>Любой нормальный протокол RPC (RMI, DCOM, CORBA) может исопльзоваться для агентного программирования. И что дальше?
Опять демагогия. Я с тем же успехом могу сказать, что "любой нормальный сетевой протокол (TCP, UDP, DecNET, IPX) может использоваться для агентного программирования". RPC — это всего лишь носитель, а агентный протокол — гораздо более выского уровня сущность.
C>И чем именно таким развлекаются программисты на Java? SOAPом?
SOAP — это тоже всего лишь носитель. Я про всякие там BOND говорю.
K>> У пользователей Схемы или Тикла получается лучше. C>Примеры, примеры?
Да какие тут примеры — почти *любой* протокол у Лисперов и Схемщиков к агентному сводится. Благодаря наличию eval в языке.
C>>>Ну и OLE к .NET не имеет никакого отношения. Может не стоит показывать C>>>своего незнания в обоих предметах? K>> Я же сказал — в .NET есть интерфейс к OLE. Скажешь, нет? :-O C>Нет. Покажи мне реализацию или обертку IViewObject в стандартной библиотеке .NET, например.
Посмотрю.
C>Может хватит свое незнание демонстировать?
Признаю, что мог тут промахнуться.
K>> Имеет, имеет. Они должны идеально интегрироваться в документооборот. C>Нормальные SCM ортогональны к остальным системам. Знаменитый Unix way в вашем понимании — создание системы из независимых интероперирующих компоненов.
thanx, посмотрю.
K>> А уж обеспечить гарантированную целостность проектной документации, системы автоматического тестирования, системы багтрекинга и документации к коду, пользуясь вордом — это задача века, за её решение надо конный памятник в масштабе 1:50 ставить. Из чистого золота. Прижизненный. C>Опять же, к целостности документации автотестер отношения не имеет НИКАКОГО — он работает с номерами ревизий и именами веток. Все что ему нужно знать — это куда пихать отчеты и куда слать нотификации об ошибках.
Как это никакого? В документации я цветом отмечаю оттестированные и поломанные интерфейсы. И в общей проектной диаграмме, собранной из этой документации — тоже отмечен процент завершенности каждой из компонент и сетепень серьёзности проблем. Ну и количество незакрытых багов в багтрекинге. Всё в одном документе. Который постоянно висит на десктопе. Знаете ли, очень удобно. Ну да любителям ворда не понять, что такое настоящая интеграция.
C>С багтрекингом и планированием немного сложнее — для планирования используется комбинация Jira/MS-Project, причем Jira мы специально дописали для совместной работы с MS-Project (Да! Работая через COM из Java!).
Любите же вы трудности себе создавать...
K>> Как не было? Было. И все были успешно проигнорированы. K>> Например, очень смешно замяли тему про ООП в GUI. C>То есть? С удовольствием отвечу подробнее, если интересно.
Я же предлагал рассмотреть пример Mathematica (точнее mathview). Как аналогичная задача решалась бы в рамках ОО, без всяких unix way-ных приколов вроде DPS?
Здравствуйте, Cyberax, Вы писали:
C>Все проекты у нас управляются через LDAP, так что для создания нового C>проекта надо заполнить всего одну форму и будет создано: C>1. Нужные почтовые ящики. C>2. Структура репозитория. C>3. Проекты в Jira/Confluence. C>4. Участникам проекта будут предоставлены необходимые права к C>репозиторию и файловому хранилищу проекта. C>5. Участники будут добавлены в нужные списки рассылки. C>6. И т.п.
И чем тут COM помогает? У меня аналогичная система работает практически из коробки, из открытых и свободных деталек собранная на коленке, и сотни строк собственного кода написано не было.
eao197 wrote: > C>С другой стороны, с COM/.NET сериализацию делать вообще НЕ надо. Можно > C>сразу передавать графы объектов. > Которые только COM-ом и .NET-ом будут пониматься. В отличии от тех же > XML-RPC или SOAP.
Ну а кто говорил, что будет легко?
COM зато поддерживается большим количеством языков, а Java RMI и .NET
могут нормально интероперировать.
Но если нужно писать многоплатформенное распределенное приложение, то
фактически остается CORBA (со всеми ее минусами) и XML-RPC/SOAP (с их
еще большим количеством минусов).
Вот был бы достаточно стандартный и распространенный бинарный объектный
RPC-протокол. Так ведь нету
> C>Нет уж. Способ проектирования приложения из частей — это называется > C>"здравый смысл" > Читая местные сообщения мне кажется, что Unix way -- это здравый смысл в > чистом виде. Не даром Реймонд философию Unix характеризует всего одним > принципом: KISS.
Не отрицаю, Unix сделан очень красиво. Только вот средств Unix'а не
хватает для десктопных приложений.
> C>Unix way — это именно приложения, интероперирующие через > C>пайпы/файлы/командную строку. > Еще сокеты забыл. И кстати, не знаешь, почему Реймонд приводит в > качестве примера PostgreSQL > <http://www.faqs.org/docs/artu/ch07s02.html#id2922148>, в котором > процессы между собой через сокеты общаются?
Это пример модульного проектирования.
Еще пример — Windows NT/2k/XP. Многие функции WinAPI в нем реализованы в
сервере CSRSS.exe, который отделен от пользовательского процесса и от
ядра. Для передачи вызовов используется LPC (Local Procedure Call).
> C>Если под "unix way" понимать создание модульных приложений — то > C>естественно. Причем Unix'ом оно не ограничивается > Модульном в том смысле, что каждый модуль, это отдельный процесс, > взаимодействующий с другими через IPC.
А что такое IPC? Out-of-proc COM — это уже IPC, RMI — это тоже IPC.
> Если оно будет допускать прозрачную смену клиента/сервера на написанные > на совершенно других языках. Например, чтобы к серверу, написанному на > C++ и работающему под Windows без проблем подключался Python-овый клиент > из-под Solaris-а. Если так, то таки-да, будет Unix way
Ну так к DCOM тоже можно подключаться из под Solaris'а — какие проблемы?
Реализуем протокол — и вперед.
K>>> Моя аналогия предельно ясна — нельзя плясать от GUI, от морды.
M>>Можно. Плясание именно от морды — это наипервейшее требование разработки Web-приложений.
K> А я вот ни разу от морды не плясал. Всегда плясал от workflow, логики и структур данных. Что я делал не так? Почему всё получалось быстрее, надёжнее и эффективнее чем у всяких любителей сначала морду нарисовать, а потом думать, все ли ветки workflow покрыты и не теряется ли состояние при переходе между элементами интерфейса.
Все так. Только в Web'e весь этот workflow вокруг UI и вертится Специфика
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Cyberax, Вы писали:
C>Вот был бы достаточно стандартный и распространенный бинарный объектный C>RPC-протокол. Так ведь нету
И на фиг не нужен. Имхо, RPC -- это вообще опиум для народа.
>> C>Если под "unix way" понимать создание модульных приложений — то >> C>естественно. Причем Unix'ом оно не ограничивается >> Модульном в том смысле, что каждый модуль, это отдельный процесс, >> взаимодействующий с другими через IPC. C>А что такое IPC? Out-of-proc COM — это уже IPC, RMI — это тоже IPC.
Так ты же сам знаешь, что такое IPC, так зачем спрашивать?
Только вот зачем Out-of-proc COM, если можно обычный сокет и прозрачный протокол использовать?
C>Ну так к DCOM тоже можно подключаться из под Solaris'а — какие проблемы? C>Реализуем протокол — и вперед.
Вот именно в этом и проблема.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Вот был бы достаточно стандартный и распространенный бинарный объектный C>RPC-протокол. Так ведь нету
И не надо такого счастья. Т.к. RPC — это зло. А COM-РПЦ — это двойное зло, неисцельная болезнь, некуоротимый зверь.
У нас расчетный сервер вначале работал через комовский RPC+shared mem. Это был сплошной и жестокий гемморой.
Во первых на сервере приходилось делать дополнительный поток который отслеживал не сдох ли клиент чтобы гасить сервер.
Во вторых танцы с бубном вокруг регистрации комовских компонентов. Какой сервер последний зарегестрировался в реестре тот и запустится — геморой с дебагжной и релизной сборкой.
В третих программирвать крайне неудобно, т.к. вся "крастота" РПЦ-вызовов сводилась на нет обилием костылей без которых никак не обойтись.
В итоге СОМ/RPC отправился в топку, были заюзаны два пайпа и наступила благодать .
M>Все так. Только в Web'e весь этот workflow вокруг UI и вертится Специфика
е-а. Workflow всё же первичен. UI рождается уже на основе анализа workflow. Когда это делается в обратном порядке — нежданчики случаются. Ну да вы наверняка в курсе, такие нежданчики в каждом проекте были, после чего всем становилось ясно (задним умом все крепки), что надо было формальнее к проектированию подходить, и дизайнерам покрепче ручки выкручивать.
eao197 wrote: > C>Вот был бы достаточно стандартный и распространенный бинарный объектный > C>RPC-протокол. Так ведь нету > И на фиг не нужен. Имхо, RPC -- это вообще опиум для народа.
Ага, первое правило распределенного программирования — "Do not distribute!".
Но иногда без RPC плохо. А привязки CORBA к C++ — это такое @#$&@#.
> C>А что такое IPC? Out-of-proc COM — это уже IPC, RMI — это тоже IPC. > Так ты же сам знаешь, что такое IPC, так зачем спрашивать?
Так просто
> Только вот зачем Out-of-proc COM, если можно обычный сокет и прозрачный > протокол использовать?
А если нужно передавать сложные объекты? Тогда придется тратить время на
бесполезный парсинг.
> C>Ну так к DCOM тоже можно подключаться из под Solaris'а — какие проблемы? > C>*Реализуем протокол — и вперед.* > Вот именно в этом и проблема.
А *сложный* текстовый протокол, думаешь, проще реализовать? Ну и с RPC
плюс в том, что достаточно его реализовать один раз, а потом
использовать.
Kluev wrote: > C>Вот был бы достаточно стандартный и распространенный бинарный объектный > C>RPC-протокол. Так ведь нету > И не надо такого счастья. Т.к. RPC — это зло.
Просто надо уметь его готовить
> А COM-РПЦ — это двойное зло, неисцельная болезнь, некуоротимый зверь.
Ага. Как и все у МС.
Здравствуйте, Cyberax, Вы писали:
C>Ага, первое правило распределенного программирования — "Do not distribute!".
В первый раз слышу.
>> Только вот зачем Out-of-proc COM, если можно обычный сокет и прозрачный >> протокол использовать? C>А если нужно передавать сложные объекты? Тогда придется тратить время на C> бесполезный парсинг.
Нормальная сериализация делает передачу сложных объектов очень тривиальной задачей.
А время -- это должен профайлер показывать, что здесь есть бутылочное горлышко.
>> C>Ну так к DCOM тоже можно подключаться из под Solaris'а — какие проблемы? >> C>*Реализуем протокол — и вперед.* >> Вот именно в этом и проблема. C>А *сложный* текстовый протокол, думаешь, проще реализовать? Ну и с RPC C>плюс в том, что достаточно его реализовать один раз, а потом C>использовать.
Сложный текстовый протокол не обязательно реализовывать в полном объеме. Если мне нужно что-то передать на сервер в HTTP GET, то для этого совсем не обязательно реализовывать весь HTTP.
К тому же тестовые протоколы легче расширяются, чем RPC интерфейсы, поскольку такие расширения можно просто пропускать, если в них не заинтересован.
Ну и кроме того, если текстовый протокол никак не катит, то можно и бинарные протоколы использовать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Kluev wrote: >> C>Вот был бы достаточно стандартный и распространенный бинарный объектный >> C>RPC-протокол. Так ведь нету >> И не надо такого счастья. Т.к. RPC — это зло. C>Просто надо уметь его готовить
Игра не стоит свеч. Полмесяца убил а толку как с козла молока. В то время как IPC на пайпах был сделан за полдня и заработал сразу просто и безотказно как трехлинейная винтовка.
Нафига тогда осваивать сложную геморойную технологию, которая легко заменяется простой и безгеморойной.
Здравствуйте, Kolhoz, Вы писали:
DK>>У простого юзера винды НЕТ X-Window, в отличие от WinAPI, что бы там офигевшие и зазнавшиеся линуксоиды не говорили K> И кого волнуют простые юзеры винды? Мы про них тут вообще не говорим.
Их >90 процентов от пользователей персональных компьютеров на планете.
Ваша фраза напоминает "а кому нужно это быдло, тут об интеллигенции базар"
Здравствуйте, DJ KARIES, Вы писали:
K>> И кого волнуют простые юзеры винды? Мы про них тут вообще не говорим. DK>Их >90 процентов от пользователей персональных компьютеров на планете. DK>Ваша фраза напоминает "а кому нужно это быдло, тут об интеллигенции базар"
Правильно, над еще добавить, что как программисты мы пишем именно для них. Интересно а для кого пишет товарищ колхозник ?
Бесспорно unix очень красивая вещь, только вот зачем одним местом поворачиваются разработчики, для этих 90% обычных пользователей ?
Почему мне нужно лезть в конфиг fstab, чтобы подмонтировать винт ? Почему нет нормальной системы установки софта ? Раз линуксоиды такие умные, почему им этого не сделать ?
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Kluev wrote: > C>Просто надо уметь его готовить > Игра не стоит свеч. Полмесяца убил а толку как с козла молока.
А ты пытался использовать DCOM? Тогда неудивительно.
С ICE для С++ или RMI в Java все работает за те же полдня.
> В то время как IPC на пайпах был сделан за полдня и заработал сразу просто и > безотказно как трехлинейная винтовка.
А что произойдет, если уборщица Маша отключит на несколько минут всю сеть?
Пайп сдохнет, а ICE/RMI сможет восстановиться.
> Нафига тогда осваивать сложную геморойную технологию, которая легко > заменяется простой и безгеморойной.
Ключевое слово если. Если можно заменить без излишних проблем —
то так и надо делать.
Kisloid wrote: > Почему мне нужно лезть в конфиг fstab, чтобы подмонтировать винт ? > Почему нет нормальной системы установки софта ? Раз линуксоиды такие > умные, почему им этого не сделать ?
Как раз с системой установки софта — все нормально: "apt-get install
kde-common" и установлена вся KDE, вместе со всем X-серверами
eao197 wrote: > C>Ага, первое правило распределенного программирования — "Do not > distribute!". > В первый раз слышу.
Высказывание Мартина Фаулера: "The first rule of distributed programming
is don't do distributed programming".
> C>А если нужно передавать сложные объекты? Тогда придется тратить время на > C> бесполезный парсинг. > Нормальная сериализация делает передачу сложных объектов очень > тривиальной задачей.
Вот мы и вернулись к RPC.
RPC — это фактически как раз и есть нормальная сериализация объектов и
их посылка по сети (забудем пока про обеспечение безопасности,
восстановлении от сбоев и т.п.).
> А время -- это должен профайлер показывать, что здесь есть бутылочное > горлышко.
Проблема в том, что это может не быть бутылочным горлом, но если вся
система так построена, то она в целом просто может быть медленной.
> C>А *сложный* текстовый протокол, думаешь, проще реализовать? Ну и с RPC > C>плюс в том, что достаточно его реализовать *один* раз, а потом > C>использовать. > Сложный текстовый протокол не обязательно реализовывать в полном объеме. > Если мне нужно что-то передать на сервер в HTTP GET, то для этого совсем > не обязательно реализовывать весь HTTP.
HTTP — это несложный протокол. Я вот на досуге пытаюсь прикрутить http://www.xref-tech.com/xrefactory/main.html к своей программе — вот
там действительно извращенский протокол.
> К тому же тестовые протоколы легче расширяются, чем RPC интерфейсы, > поскольку такие расширения можно просто пропускать, если в них не > заинтересован.
В RPC — аналогично. В правильном RPC.
> Ну и кроме того, если текстовый протокол никак не катит, то можно и > бинарные протоколы использовать.
А какая разница?
Здравствуйте, Cyberax, Вы писали:
C>Высказывание Мартина Фаулера: "The first rule of distributed programming C>is don't do distributed programming".
Не хорошо пинать классиков, но здесь я с ним не соглашусь
C>RPC — это фактически как раз и есть нормальная сериализация объектов и C>их посылка по сети (забудем пока про обеспечение безопасности, C>восстановлении от сбоев и т.п.).
RPC -- это прежде всего эмуляция синхронного вызова.
>> А время -- это должен профайлер показывать, что здесь есть бутылочное >> горлышко. C>Проблема в том, что это может не быть бутылочным горлом, но если вся C>система так построена, то она в целом просто может быть медленной.
Тоже самое можно сказать и об RPC.
C>В RPC — аналогично. В правильном RPC.
Интересно, вот требуется в некий вызов добавить парочку параметров. Как это сделать в RPC кроме как добавить новый вызов?
>> Ну и кроме того, если текстовый протокол никак не катит, то можно и >> бинарные протоколы использовать. C>А какая разница?
С бинарными сложнее работать в том же Ruby.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Kolhoz, Вы писали:
K>>> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, K>>> преимущественно под Windows, и ну ни разу не приходилось применять их, K>>> вендовый стиль мышления. К чему бы это? C>>Ну так покажите эти GUI. И их пользователей. Какие проблемы? AB>Я так понимаю, что образец GUI для подражания в количестве "много" нам не покажут? K> Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview.
Т.е. это твоя разработка? Дело в том, что я хочу посмотреть на гуй под винду, к которому не применялся виндовый стиль мышления и, который сделан именно тобой, согласно заявлению. Т.е. цели моего вопроса можно разбить на 3 части:
1. Я хочу понять, чем эти два подхода так сильно отличаются (понять визуально [если не сложно, то скриншотики с подробными комментариями], поюзать, если возможно [URL для скачивания]).
2. Хочу оценить сложность создания подобного одним человеком, который говорит, что этот гуй хорош.
3. Все обдумать, взвесить, и, при удобном случае, попытаться попользовать.
K> Я пока так и не услышал у апологетов объектной компонентности внятных идей о том, как аналогичную мощь и гибкость реализовать их смешными методами.
В данном случае, мой вопрос к теме, наверное, не относится, а выносить его в отдельную ветку не хотелось.
Здравствуйте, Cyberax, Вы писали:
>> C>Ну так покажите эти GUI. И их пользователей. Какие проблемы? >> Я так понимаю, что образец GUI для подражания в количестве "много" нам >> не покажут? C>Из своего я могу только скриншоты наделать, а по ним не очень понятно C>что и как работает.
Меня интересует только "свой", за которым стоит реальный человек, доказывающий точку зрения в данной ветке. Достаточно скриншотов с объяснением своего видения на них.
Здравствуйте, Kisloid, Вы писали:
K>Почему мне нужно лезть в конфиг fstab, чтобы подмонтировать винт ? Почему нет нормальной системы установки софта ? Раз линуксоиды такие умные, почему им этого не сделать ?
Удобные системы установки есть в Debian, Gentoo, SuSe. Во Free-ях так же двигаются в сторону удобства не программистов: http://www.pcbsd.org/
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > C>Высказывание Мартина Фаулера: "The first rule of distributed programming > C>is don't do distributed programming". > Не хорошо пинать классиков, но здесь я с ним не соглашусь
Нет, правило хорошее. Если что-то можно не распределять — то лучше не
распределять.
> C>RPC — это фактически как раз и есть нормальная сериализация объектов и > C>их посылка по сети (забудем пока про обеспечение безопасности, > C>восстановлении от сбоев и т.п.). > RPC -- это прежде всего эмуляция синхронного вызова.
Ничуть. Это "вызов удаленных процедур", и эмуляция прямого синхронного
вызова — лишь один из вариантов.
Не самый лучший, IMHO, так как не учитывает многие проблемы.
> C>Проблема в том, что это может не быть бутылочным горлом, но если вся > C>система так построена, то она в целом просто может быть медленной. > Тоже самое можно сказать и об RPC.
Ну да. Отсюда первое правило распределенного программирования.
У RPC плюс в меньшем оверхеде. Например, в Java вызов через RMI в 50
(пятьдесят) раз быстрее того же вызова через SOAP.
> C>В RPC — аналогично. В *правильном* RPC. > Интересно, вот требуется в некий вызов добавить парочку параметров. Как > это сделать в RPC кроме как добавить новый вызов?
Добавить новый метод с двумя параметрами А как ты это в С++ делаешь?
Здравствуйте, Cyberax, Вы писали:
>> C>Высказывание Мартина Фаулера: "The first rule of distributed programming >> C>is don't do distributed programming". >> Не хорошо пинать классиков, но здесь я с ним не соглашусь C>Нет, правило хорошее. Если что-то можно не распределять — то лучше не C>распределять.
Как раз у меня есть противоположный собственный опыт. То, что казалось бы, может работать монолитом, выигрывает по некоторым параметрам (надежность, масштабируемость) будучи распределенным.
C>Ничуть. Это "вызов удаленных процедур", и эмуляция прямого синхронного C>вызова — лишь один из вариантов.
Я говорил об RPC именно как о Remote Procedure Call, а call -- это синхронный вызов. И вся цель RPC в том, чтобы скрыть от программиста факт распределенности.
>> C>В RPC — аналогично. В *правильном* RPC. >> Интересно, вот требуется в некий вызов добавить парочку параметров. Как >> это сделать в RPC кроме как добавить новый вызов? C>Добавить новый метод с двумя параметрами А как ты это в С++ делаешь?
В том-то и дело, что в C++ я делаю метод, но вынужден оставлять и старый для совместимости. Либо рефакторить код, чтобы убрать использование старого метода. Между тем, если метод изначально имел формат:
void do_something( const params_t & params );
то расширение структуры params_t не будет сказываться на вызовах do_something.
Вот тестовые протоколы, которые должным образом структурируют информацию (как, например, заголовки HTTP, XML, YAML) как раз позволяют использовать подобный прием.
В бинарном формате такие фокусы позволяют проделывать ASN1 представления (ну и моя ObjESSty ). Однако, как я уже говорил, с бинарными данными приходится больше возиться при их портировании на другие языки программирования.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > C>Нет, правило хорошее. Если что-то можно не распределять — то лучше не > C>распределять. > Как раз у меня есть противоположный собственный опыт. То, что казалось > бы, может работать монолитом, выигрывает по некоторым параметрам > (надежность, масштабируемость) будучи распределенным.
Сравни сложность разработки — распределенные приложения заметно сложнее
отлаживать и писать.
> C>Ничуть. Это "вызов удаленных процедур", и эмуляция прямого синхронного > C>вызова — лишь один из вариантов. > Я говорил об RPC именно как о Remote Procedure Call, а call -- это > синхронный вызов. И вся цель RPC в том, чтобы скрыть от программиста > факт распределенности.
Такой RPC мне самому не нравится — слишком много проблем вызывает.
А вот что-нибудь типа JMS в Java — вполне себе ничего.
> C>Добавить новый метод с двумя параметрами А как ты это в С++ делаешь? > В том-то и дело, что в C++ я делаю метод, но вынужден оставлять и старый > для совместимости. Либо рефакторить код, чтобы убрать использование > старого метода. Между тем, если метод изначально имел формат: > > void do_something( const params_t & params ); > > то расширение структуры params_t не будет сказываться на вызовах > do_something.
Ну так никто не мешает делать это и в RPC.
> Вот тестовые протоколы, которые должным образом структурируют информацию > (как, например, заголовки HTTP, XML, YAML) как раз позволяют > использовать подобный прием.
Просто сам по себе HTTP запрос представляет вызов одного метода примерно
такого типа:
int processData(std::map<std::string,std::string> params,
std::map<std::string,std::string> &result, std::string &result);
Здравствуйте, Cyberax, Вы писали:
C>Сравни сложность разработки — распределенные приложения заметно сложнее C>отлаживать и писать.
Сравнил. Обрати внимание на название инструмента в моей подписи
Там самое сложное -- это привыкнуть к асинхронности на первом этапе. Затем, при использовании нескольких дополнительных библиотечек, что монолитное, что распределенное приложение -- уже нет разницы. Так что инструменты здесь играют очень и очень важную роль.
>> Я говорил об RPC именно как о Remote Procedure Call, а call -- это >> синхронный вызов. И вся цель RPC в том, чтобы скрыть от программиста >> факт распределенности. C>Такой RPC мне самому не нравится — слишком много проблем вызывает.
Так собственно это и есть RPC...
C>А вот что-нибудь типа JMS в Java — вполне себе ничего.
А вот это уже еще один вид IPC
>> Вот тестовые протоколы, которые должным образом структурируют информацию >> (как, например, заголовки HTTP, XML, YAML) как раз позволяют >> использовать подобный прием. C>Просто сам по себе HTTP запрос представляет вызов одного метода примерно C>такого типа: C>
Здравствуйте, Kisloid, Вы писали:
K>Мне Мигель говорил что C# 2.0 поддерживается на 90%, причем 10% это баги Это было давно, примерно полгода назад.
В лучшем случае к выходу C# 3.0 компилер стабилизируют в объёме C# 2.0, а окружающие библиотеки так и будут ущербными,
что сводит на нет все радости существования компилятора и Mono вообще.
Просто это изначально проигрышная позиция догонять, да ещё таких мастеров несовместимости и забивания на стандарты как MS.
Здравствуйте, iZEN, Вы писали:
ZEN>Да у них на сайте чёрным по белому написано. Не могут решить, какую версию библиотеки GTK использовать и ZEN>использовать ли её вообще для реализации WinForms. Месяц назад смотрел специально.
Ссылку пдай. А то я что-то не вижу.
VD>>С компонентным подходм в Моно проблем нет. Тот же компилятор Немерле использует компонентный подход для динамической подгрузки макросов. ZEN>Про языки будем отдельно говорить, так и Delphi/Kylix можно подцепить.
Такое ощущение что мы говорим через испорченный телефон. Причем тут Кликс? Немереле использует штатные компонентые средства Моно и дотнета.
Что непонятного в моих словах?
ZEN>В теме рассматривается проблема: а так ли хорошо реализован КОП в Linux или не очень хорошо.
В теме задается вопрос "если ли КОП в Линукс". А этот вопрос ты сам только что придумал.
Собственно мой ответ в том, что переносимые среды воде Явы и дотнета обеспечивают компонентность на любой ОС где их установали.
Если тебе хочется пофанатсвовать и помериться пенисами в области Ява вс. дотнет, то открывай новую тему. И лучше сразу во Флэйме.
ZEN>Пока все склоняются в сторону того, что КОП в Linux реализован иначе, не как в Windows, но в любом случае использование подхода КОП как в Windows тоже не возбраняется. ZEN>В Windows, например, очень трудно использовать подход UNIX просто из-за того, что пользователи (программисты и просто пользователи) зашорены идеологией виндовс и не способны мыслить иначе, чем кнопочками, диалогами и командой "Выполнить".
Ты точно понимашь под термином КОП то что все остальные?
Что за компоентный подход ты усмотрел в самих Виндовс и загадочном Юникс (видимо Линукс).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Другое дело, я действительно люблю когда все работает out of the box. АХ>Нажал кнопку "Установить" — все установилось , "выполнить" — выпонилось АХ>и не люблю по запутанным мануалам изучать значения флагов в командной строке. АХ>Пусть простые задачи будут простыми.
Причем тут КОП? КОП — Компонетно Ориентированное Программирование. То есть взгляд на программу как на собираемую из отдельных компонентов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
>> C>Нет, правило хорошее. Если что-то можно не распределять — то лучше не >> C>распределять. >> Как раз у меня есть противоположный собственный опыт. То, что казалось >> бы, может работать монолитом, выигрывает по некоторым параметрам >> (надежность, масштабируемость) будучи распределенным. C>Сравни сложность разработки — распределенные приложения заметно сложнее C>отлаживать и писать.
А как же Эрланг?
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Kisloid, Вы писали:
K>Вот тогда следующий вопрос, возьмем к примеру Мозилловские проекты, зачем им надо было создавать свою реализацию КОМа если есть unix way (хотя наверное вопрос к ним ) ?
Замечательный вопрос. Четко демонстрирующий то, что под компонентным подходом в Уних-вэях понимают совсем другое.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, iZEN, Вы писали:
ZEN>И что? Сейчас три вышеперечисленные мною компании в открытую спонсируют ECMA, не говоря уже о мелких конторках. Но почему-то IBM и Sun не спешат присоединяться.
Ты хоть понимашь что такое ECMA и чем эта организация отличается от ANSI, к примеру?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
АХ>>Еще посмотрим, когда Mono доделают как он на Unix системах развернется . EC>Не доделают его — это нереально.
А ты сам то Моно пробовал?
EC>Он обречён на отставание. EC>Посмотри с какой скоростью плодятся всякие C# 3.0, LINQ, ADO.NET 3, WCF, WPF и прочие buzzwords.
Нда, знания на уровре фантастики. C# 3.0, LINQ, ADO.NET вообще от платформы не зависят.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>В лучшем случае к выходу C# 3.0 компилер стабилизируют в объёме C# 2.0, а окружающие библиотеки так и будут ущербными, EC>что сводит на нет все радости существования компилятора и Mono вообще.
А ты вкурсе, что сборки от C# 3.0 без перекомпиляции можно запускать под .NET 2.0 и Моно?
Что до библиотек, то их уже точно больше чем можно найти в поставке какого-нибудь С++-компилятора.
EC>Просто это изначально проигрышная позиция догонять, да ещё таких мастеров несовместимости и забивания на стандарты как MS.
Любой С++-компилятор догоняет стандарт С++. Пока только один догнал текущий стандарт.
Внимание, вопрос! С++ обречен?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Другое дело, я действительно люблю когда все работает out of the box. АХ>>Нажал кнопку "Установить" — все установилось , "выполнить" — выпонилось АХ>>и не люблю по запутанным мануалам изучать значения флагов в командной строке. АХ>>Пусть простые задачи будут простыми.
VD>Причем тут КОП? КОП — Компонетно Ориентированное Программирование. То есть взгляд на программу как на собираемую из отдельных компонентов.
Это была моя реакция на
пользователи (программисты и просто пользователи) зашорены идеологией виндовс и не способны мыслить иначе, чем кнопочками, диалогами и командой "Выполнить".
Здравствуйте, Kolhoz, Вы писали:
АХ>>то что вы пишете в Unix как АХ>>"ls | more" АХ>>можно записать как (условно) АХ>>"File result = more.Process( ls.Process(input) )". АХ>>more и ls некие компоненты.
АХ>>Чуть больше слов, но суть та же.
K> Не та же. Я не могу между more и ls вставить в этой модели ничего (sort, например).
Почему?
"File result = more.Process( sort.Process( ls.Process(input) ) )"
Как я уже говорил, на мой взгляд вся эта работа через каналы — частный случай КОП.
K>>> Дао Unix way: K>>>- на каждую функциональную единицу — отдельный компонент АХ>>Правильно — в любой компонентной системе так.
K> Не в любой. В объектных моделях для этого функциональная единица должна совпадать с объектом. А это не всегда возможно. Скорее, это почти никогда не возможно — объектная иерархия редко совпадает с семантической.
Почему это она не должна совпадать с семантической?
K>>>- к компоненту предъявляются требования: K>>> * возможность как программного так и интерактивного задействования всех его функций. АХ>>Правильно. Так как вы там интерактивность в Unix way обеспечиваете?
K> Не понял вопроса. Легко и непринуждённо обеспечиваем.
Ну и как вы будете игру (не многопользовательскую, а самую обычную) писать через Unix way?
K>>> * корректное сообщение о любых исключительных ситуациях АХ>>Сообщение мало. Надо еще данные не убить по возможности. АХ>>Без поддержки исключений обработка ошибок — это геморрой жуткий. АХ>>Я уж не говорю про RAII. А это предполагает ОО.
K> ОО тут совершенно не при делах...
Аргументируй.
АХ>>Эээ. Вот тут мне видится фундаментальный изъян. АХ>>Дело в том что для того чтобы вставить на вход одного компонента выхлоп из другого нужно чтобы у них были совместимы интерфейсы, т.е. передаваемая информация была в одном формате, АХ>>в unix way используется наименьший общий знаменатель — простой текст.
K> Не обязательно. Не нужна совместимость, на самом деле.
Как это так? Подаем ASCII а программа хочет Unicode и привет!
АХ>>Вот LaTeX — это Unix way? АХ>>в цепочке "latex -> dvips -> ps2pdf" ты можешь вставить (точнее, смысл есть?) между dvips и ps2pdf grep?
K> Могу, и как правило вставляю (psnup, ps2ps, мелкие самописные пошкрип-фильтры). Смысла много — postscript обрабатывать весело, легко и просто, буклетик там из него сшить, водяные знаки наложить, или ещё что, а вот pdf потом править обломно будет. Так уж лучше я поправлю ps на этом этапе.
Правильно, но это уже не ЛЮБЫЕ, а специализированные компоненты, предназначенные для обработки ps.
K>>> Всё. Текстовые потоки, awk-и с netcat-ами — это частности и следствия означенного дао. АХ>>Имеют свои плюсы, но не универсальны.
K> Естественно. А Unix way не требует использования обязательно текстовых потоков.
А как же тогда вы между ЛЮБЫМИ двумя компонентами третий вставите?
AX>> Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .
K> Простите, какие языки? Какая функциональщина? Мне глубоко наплевать на ОО и функциональщину в языках. Наплевать и растереть.
А позволь поинтересоваться на каких языках ты пишешь?
K> В данном случае источник мирового зла — это OOD, то есть, ОО на уровне проектирования, на компонентном уровне.
Ужас какой-то. И чем тебя OOD угнетает? Это американский заговор, да?
K> Тут пока никаких языков нет и не предвидится.
Где тут?
Здравствуйте, VladD2, Вы писали:
VD>А ты вкурсе, что сборки от C# 3.0 без перекомпиляции можно запускать под .NET 2.0 и Моно?
А как насчёт коммерческих GUI библиотек, которые кишат p/invoke & interop? А как быть с пространствами
имён типа System.Diagnostics, System.Threading, System.EnterpriseServices, System.Drawing,
реестр и прочая виндовая байда, которая на юнихи никак не ложиться? GDI, COM, COM+, DTS туда же.
Реализовать это всё равно, что написать половину винды.
VD>Что до библиотек, то их уже точно больше чем можно найти в поставке какого-нибудь С++-компилятора.
Причём здесь С++? Что он тебе плохого сделал, что ты его упоминаешь к месту и не к месту? Речь идёт
о КОП в linux, C++ к нему (КОП) никаким боком (причём именно ты об этом чаще всех говоришь).
VD>Любой С++-компилятор догоняет стандарт С++. Пока только один догнал текущий стандарт.
VD>Внимание, вопрос! С++ обречен?
С++ вообще не имеет никакого отношения к разговору — ты что-то попутал.
Здравствуйте, VladD2, Вы писали:
VD>А ты сам то Моно пробовал?
Я с UNIX знаком достаточно хорошо, чтобы понимать НАСКОЛЬКО он отличается от винды
и поэтому представляю себе сложность портирования BCL на UNIX.
А на винде его использовать вообще смысла нет.
Только не рассказывай мне, что BCL и C# это разные вещи — это я и так понимаю.
Но без BCL, C# большинству его пользователей вообще не упал, в C# нет ничего такого,
что давало бы ему хоть какие-то преимущества например перед Java — вся соль в библиотеках
и интеграции с операционкой, а коли их не будет, то он пойдёт фтопку.
VD>Нда, знания на уровре фантастики. C# 3.0, LINQ, ADO.NET вообще от платформы не зависят.
Ты у меня ещё экзамен прими, эксперт по оценке чужих знаний.
Формально да — не зависят, но без LINQ и в особенности ADO.NET привлекательность .NET как платформы существенно снижается.
Здравствуйте, Cyberax, Вы писали:
>> Как раз у меня есть противоположный собственный опыт. То, что казалось >> бы, может работать монолитом, выигрывает по некоторым параметрам >> (надежность, масштабируемость) будучи распределенным. C>Сравни сложность разработки — распределенные приложения заметно сложнее C>отлаживать и писать.
Узость мышления. Переключитесь на другую парадигму — и наоборот, распределённые системы, построенные на обмене сообщениями будут для вас гораздо проще императивных однопоточных последовательных систем. Вы же пытаетесь в рамках привычных вам сущностей выписать чуждые структуры — и поражаетесь их якобы "сложности". Ну так машина Тьюринга на XSLT тоже аццки сложная получается. Или Форт на Intercal-е.
Здравствуйте, Андрей Хропов, Вы писали:
K>> Не та же. Я не могу между more и ls вставить в этой модели ничего (sort, например). АХ>Почему? АХ>"File result = more.Process( sort.Process( ls.Process(input) ) )" АХ>Как я уже говорил, на мой взгляд вся эта работа через каналы — частный случай КОП.
Нельзя менять код ни одного из компонентов.
K>> Не понял вопроса. Легко и непринуждённо обеспечиваем. АХ>Ну и как вы будете игру (не многопользовательскую, а самую обычную) писать через Unix way?
Опять не понял вопроса? Что мешает? Логика и AI — одним процессом (причём AI — на скриптовом языке), графический движок — другим, всё это вместе завёрнуто в скриптовую обёртку третьим процессом, чтение и разгрёб конфигурации — четвёртым.
K>>>> * корректное сообщение о любых исключительных ситуациях АХ>>>Сообщение мало. Надо еще данные не убить по возможности. АХ>>>Без поддержки исключений обработка ошибок — это геморрой жуткий. АХ>>>Я уж не говорю про RAII. А это предполагает ОО.
K>> ОО тут совершенно не при делах... АХ>Аргументируй.
Не мне это надо делать. Это вам бы показать, как объектная модель позволяет достичь при исключительной ситуации большего чем корректное сообщение. Я таких фичей у ОО не наблюдаю.
Кстати, на заметку: исключение — это очень не-ОО сущность. И в компонентных ОО-моделях аналога исключений как бы даже и нет. Обидно, да?
K>> Не обязательно. Не нужна совместимость, на самом деле. АХ>Как это так? Подаем ASCII а программа хочет Unicode и привет!
А между ними встраивается iconv, и здрасте.
K>> Могу, и как правило вставляю (psnup, ps2ps, мелкие самописные пошкрип-фильтры). Смысла много — postscript обрабатывать весело, легко и просто, буклетик там из него сшить, водяные знаки наложить, или ещё что, а вот pdf потом править обломно будет. Так уж лучше я поправлю ps на этом этапе. АХ>Правильно, но это уже не ЛЮБЫЕ, а специализированные компоненты, предназначенные для обработки ps.
И что? А надо вставлять wc, строки в ps считать? Зачем? Хотя, grep+wc у меня пару раз было в пайплайне за генерёжкой ps сразу — когда надо было статистику количества страниц вести. Только это всё к теме не относится. То, что я описал (psnup и компания) — это чистейший unix way.
K>> Естественно. А Unix way не требует использования обязательно текстовых потоков. АХ>А как же тогда вы между ЛЮБЫМИ двумя компонентами третий вставите?
Опять не понял, где вы затруднения углядели. Что я, не могу враппер подсунуть, который по popen() дёрнется вместо другой программки? Не могу на сокет повесить свою прослойку? Да у меня частенько ssh-форвардинг в качетсве быстрых временных затычек в сложных распределённых системах влезает, а в коде этих систем никому и знать не надо, что соединения перехватываются и данные дополнительно обрабатываются. Бинарные данные, кстати.
AX>>> Теперь уже дальше идем в сторону скрещения ОО с функциональщиной . Даже в скриптовых языках, без которых Unix way никуда .
K>> Простите, какие языки? Какая функциональщина? Мне глубоко наплевать на ОО и функциональщину в языках. Наплевать и растереть. АХ>А позволь поинтересоваться на каких языках ты пишешь?
А какое это имеет значение? См. моё дао — из него ясно следует, что язык роли не играет. Дао работает с любыми языками. Но мы то сейчас не про языки говорим, а про уровень компонентов.
K>> В данном случае источник мирового зла — это OOD, то есть, ОО на уровне проектирования, на компонентном уровне. АХ>Ужас какой-то. И чем тебя OOD угнетает? Это американский заговор, да?
Вы потеряли нить разговора. Начисто. Постарайтесь подумать ещё раз — на каком уровне абстракции мы выстраиваем компонентную модель? Какие методы формализации предметной области мы должны применять, и какие ограничения на эти методы накладывает семантика компонентной модели? Думайте не менее получаса прежде чем ответить — а то опять скажете что-то не в тему и невпопад, опять смешно будет.
K>> Тут пока никаких языков нет и не предвидится. АХ>Где тут?
Здравствуйте, Anton Batenev, Вы писали:
K>> Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview.
AB>Т.е. это твоя разработка?
Нет конечно же. Мои разработки, увы, такого запредельного качества, неизбежно вызывающего восторг и поклонение, вызвать не могут. Так что я предпочитаю указывать на всем известный шедевр как аргумент в споре о применимости той или иной модели.
AB>1. Я хочу понять, чем эти два подхода так сильно отличаются (понять визуально [если не сложно, то скриншотики с подробными комментариями], поюзать, если возможно [URL для скачивания]).
Для mathview очень легко понять визуально разницу. Там DPS торчит из всех щелей.
AB>2. Хочу оценить сложность создания подобного одним человеком, который говорит, что этот гуй хорош.
Там много очень маленьких и простых гуёвых примочек, сделанных поверх фреймворка mathview. Оцените, как легко и просто делаются такие сложные и красивые вещи.
AB>3. Все обдумать, взвесить, и, при удобном случае, попытаться попользовать.
Для попробовать — проще всего взять Tcl/Tk, и что либо простенькое нарисовать.
Здравствуйте, Cyberax, Вы писали:
C>Иностранные поисковики на слова "agent protocol" выдают всякую фигню, а C>родной ya.ru на "агентный/агентский протокол" выдает, в основном, C>рефераты про искусственный интеллект.
C>Так что прошу примеры агентских протоколов и программ, их использующих.
И, да, это часто относят к искусственному интеллекту — но совершенно напрасно. Область применения агентной модели гораздо ширшее и глубжее.
Особенность протоколов большинства агентных систем в том, что для обмена сообщениями используется сложный, часто тьюринг-полный язык. То есть, агенты как бы программируют друг друга. Это очень сильно упрощает жизнь при разработке сильно распределённых гетерогенных систем.
C>Вообще-то у Явистов есть JMS (Java Message Service) и его адаптация для C>high-performance computing.
C>MPI, кстати, тоже есть. Поищите по словам JavaMPI и mpiJava.
Есть то он есть. Только вот его как бы и нет — производительность оставляет желать всего хорошего, заходите почаще, а лучше мы к вам. Как я матерился, когда в последний момент пришлось всё на C++ переписывать, осознав, что Java не тянет.
Здравствуйте, DJ KARIES, Вы писали:
K>> И кого волнуют простые юзеры винды? Мы про них тут вообще не говорим. DK>Их >90 процентов от пользователей персональных компьютеров на планете. DK>Ваша фраза напоминает "а кому нужно это быдло, тут об интеллигенции базар"
Нет, это ваша фраза напоминает "а фигли вы тут калачами торгуете, когда в соседнем ряду та-аких хряков завезли!". Понимаете? Мы обсуждаем архитектуру компонентных систем. И совместимость разных идеологий с физическими возможностями разных ОС. Сколько там юзеров у какой ОС в контексте данного разговора никого совершенно не колышет. Так что просто признайте, что встряли в тему, в которой вы просто ни ухом, ни рылом, попытались поумничать, и сели в лужу. Полезно, знаете ли. Остужает.
Здравствуйте, Kisloid, Вы писали:
DK>>Их >90 процентов от пользователей персональных компьютеров на планете. DK>>Ваша фраза напоминает "а кому нужно это быдло, тут об интеллигенции базар"
K>Правильно, над еще добавить, что как программисты мы пишем именно для них. Интересно а для кого пишет товарищ колхозник ?
Ещё одна легкоузнаваемая по полёту птица, не врубившаяся в тему. Право слово, смешно-с.
Особенно в свете того, что обсуждалось, как легко и непринуждённо unix way применяется в Win32.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, VladD2, Вы писали:
VD>>А ты вкурсе, что сборки от C# 3.0 без перекомпиляции можно запускать под .NET 2.0 и Моно? EC>А как насчёт коммерческих GUI библиотек, которые кишат p/invoke & interop?
Как насчет того чтобы не переводить разговор на другие темы?
VD>>Что до библиотек, то их уже точно больше чем можно найти в поставке какого-нибудь С++-компилятора. EC>Причём здесь С++?
При том, что их отсутсвие не сильно мешает разработывать ПО.
EC> Что он тебе плохого сделал, что ты его упоминаешь к месту и не к месту? Речь идёт EC>о КОП в linux, C++ к нему (КОП) никаким боком (причём именно ты об этом чаще всех говоришь).
Ну, раз о КОП, то с каой целью тут преплитаются какие-то внешние библиотеки? Что подержка КОП трубет внешних бибилотек?
VD>>Внимание, вопрос! С++ обречен? EC>С++ вообще не имеет никакого отношения к разговору — ты что-то попутал.
Ну, вот и твой разговор о библиотеках не имеет никакого отношения к делу.
Не фига притягивать что попало в качестве аргументации против очевидных вещей.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, VladD2, Вы писали:
VD>>А ты сам то Моно пробовал? EC>Я с UNIX знаком достаточно хорошо, чтобы ...поэтому ...представляю себе...UNIX.
Ясно. Значит не пробовал. Так и запишем. Кстати, что за манера вместо "нет" выдавать тирады пустых слов?
EC>Только не рассказывай мне, что BCL и C# это разные вещи — это я и так понимаю.
BCL практически полностью реализован в Моно. Как в прочем и в Роторе.
EC>Ты у меня ещё экзамен прими, эксперт по оценке чужих знаний.
Думаю, ты и сам понимаешь уровень своих знаний в этом вопросе.
EC>Формально да — не зависят, но без LINQ и в особенности ADO.NET привлекательность .NET как платформы существенно снижается.
Здравствуйте, VladD2, Вы писали:
VD>Как насчет того чтобы не переводить разговор на другие темы?
Я это к тому, что .NET как компонентная среда под Linux обладает более ограниченной сферой применения по сравнению с её реализацией под вынь. В посте, на который я отвечал речь шла о том, в каком объёме она реализована под линь. Так, что всё по теме.
EC>>Причём здесь С++?
VD>При том, что их отсутсвие не сильно мешает разработывать ПО.
Но и не помогает. И к КОП под линух отношения не имеет.
VD>Ну, раз о КОП, то с каой целью тут преплитаются какие-то внешние библиотеки? Что подержка КОП трубет внешних бибилотек?
КОП способствует разработке с их использованием
VD>Ну, вот и твой разговор о библиотеках не имеет никакого отношения к делу.
VD>Не фига притягивать что попало в качестве аргументации против очевидных вещей.
Ещё раз — я говорил об объёме раелизации конкретной среды под конкретную платформу, а до того есть ли КОП под линух мне вообще дела нет.
Здравствуйте, VladD2, Вы писали:
VD>Ясно. Значит не пробовал. Так и запишем. Кстати, что за манера вместо "нет" выдавать тирады пустых слов?
Мне достаточно того, что написано на их сайте.
VD>BCL практически полностью реализован в Моно. Как в прочем и в Роторе.
Т.е. я могу создавать Serviced Components и хостить их под моно в линухе? И они смогут участвовать в распределённых транзакциях?
Ты сам в это веришь? Может даже проверял?
VD>А LINQ — это всего лишь обертка над ним и фрэймворком. К тому же еще не существующая официально.
Для тех, кто не читает между строк — основная мысль моего поста такая: большинству пользователей среды не нужен её кастрированный вариант.
Здравствуйте, Kolhoz, Вы писали:
K>>> Лучший unix way GUI всех времён и народов (и, кстати, работавший даже под DOS) — Wolfram Mathematica, точнее ейный компонент mathview. AB>>Т.е. это твоя разработка? K> Нет конечно же.
К сожалению, по ссылке огромный объем информации, из которого понять что-либо очень сложно за короткое время. По этому я и просил что-нибудь свое, что по проще и наглядно.
K> Мои разработки, увы, такого запредельного качества, неизбежно вызывающего восторг и поклонение, вызвать не могут. Так что я предпочитаю указывать на всем известный шедевр как аргумент в споре о применимости той или иной модели.
А я ни с чем и не спорю
AB>>1. Я хочу понять, чем эти два подхода так сильно отличаются (понять визуально [если не сложно, то скриншотики с подробными комментариями], поюзать, если возможно [URL для скачивания]). K> Для mathview очень легко понять визуально разницу. Там DPS торчит из всех щелей.
Что такое DPS?
AB>>3. Все обдумать, взвесить, и, при удобном случае, попытаться попользовать. K> Для попробовать — проще всего взять Tcl/Tk, и что либо простенькое нарисовать.
Я имел ввиду вообще попытаться применить концепцию безотносительно среды.
Kolhoz wrote: > C>Сравни сложность разработки — распределенные приложения заметно сложнее > C>отлаживать и писать. > Узость мышления. Переключитесь на другую парадигму — и наоборот, > распределённые системы, построенные на обмене сообщениями будут для вас > гораздо проще императивных однопоточных последовательных систем.
Я уже давно понял, что делать распределенные или многопоточные системы
на чем-то кроме отсылки сообщений — это обычно гиблое дело.
В случае с многопоточностью — постоянные проблемы с нужными
блокировками, а с распределенными системами — проблемы с реакциями на
сбои. Хотя, конечно, бывают случаи когда обычный RPC намного удобнее.
Но даже просто системы с отсылкой сообщений все равно сложнее
отлаживать, хотя бы из-за необходимости следить за несколькими
приложениями одновременно.
Kolhoz wrote: > C>Так что прошу примеры агентских протоколов и программ, их использующих. > http://en.wikipedia.org/wiki/Agent_based > И, да, это часто относят к искусственному интеллекту — но совершенно > напрасно. Область применения агентной модели гораздо ширшее и глубжее.
В общем понятно, система представляется набором агентов, обменивающихся
сообщениями.
> Особенность протоколов большинства агентных систем в том, что для обмена > сообщениями используется сложный, часто тьюринг-полный язык. То есть, > агенты как бы программируют друг друга. Это очень сильно упрощает жизнь > при разработке сильно распределённых гетерогенных систем.
В МОРГ!!!!
Я работал с такой системой, которая интегрировала две
enterprise-системы. Для общения использовался SOAP, а для управления
control-flow — BPEL4j. Типа grid computing и все такое...
Вот только когда в реальности в одном проекте начинают работать разные
люди — обнаруживается, что это все не очень-то удобно. И часто проще
использовать обычные синхронные сетевые вызовы (что в итоге и произошло
— осталось несколько веб-сервисов, склеивающих две системы, все
остальное было написано в обычно стиле).
> C>Вообще-то у Явистов есть JMS (Java Message Service) и его адаптация для > C>high-performance computing. > C>MPI, кстати, тоже есть. Поищите по словам JavaMPI и mpiJava. > Есть то он есть. Только вот его как бы и нет — производительность > оставляет желать всего хорошего, заходите почаще, а лучше мы к вам.
Ну как бы Java не создавалась для high-perf computing. Поэтому сейчас
Sun и делает Fortress.
Здравствуйте, Cyberax, Вы писали:
>> C>Так что прошу примеры агентских протоколов и программ, их использующих. >> http://en.wikipedia.org/wiki/Agent_based >> И, да, это часто относят к искусственному интеллекту — но совершенно >> напрасно. Область применения агентной модели гораздо ширшее и глубжее. C>В общем понятно, система представляется набором агентов, обменивающихся C>сообщениями.
Здравствуйте, EvilChild, Вы писали:
VD>>Как насчет того чтобы не переводить разговор на другие темы? EC>Я это к тому, что .NET как компонентная среда под Linux обладает более ограниченной сферой применения по сравнению с её реализацией под вынь. В посте, на который я отвечал речь шла о том, в каком объёме она реализована под линь. Так, что всё по теме.
Понятно. Значит не переводить не можешь. Будем считать это признанием отсуствия аргументации по теме. Следовательно вопрос можно считать исчерпаным.
VD>>При том, что их отсутсвие не сильно мешает разработывать ПО. EC>Но и не помогает. И к КОП под линух отношения не имеет.
Естественно. Но главное здесь, то что вопрос наличия или отсуствия библиотек никак не связан с поддержкой компонентного подхода.
Софт для Линукса пишут и на С и на С++ вообще не поддерживающих этот подход. Причем при разработке на этих языках зачастую основная масса библиотек пишется разработчиками этого проекта. Так что если они воспользуются, например, Моно, то не окажутся в худших условиях, так как получа большие по объему бибиблиотеки (и что характерно библиотеки будут лучше стандартизованы и поще в использовании).
EC>Ещё раз — я говорил об объёме раелизации конкретной среды под конкретную платформу, а до того есть ли КОП под линух мне вообще дела нет.
А ты не говори, ты попробу. Понимашь, в чем дело ты говоришь о том, что явно не видел в глаза. А между тем Моно уже нехило продвинулся вперед. В нем конечно меньше классов чем в дотнете, но вполне достаточно для реализации обчень широкого класса ПО.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, EvilChild, Вы писали:
VD>>Ясно. Значит не пробовал. Так и запишем. Кстати, что за манера вместо "нет" выдавать тирады пустых слов? EC>Мне достаточно того, что написано на их сайте.
Цитаты, плиз, а мы оценим адекватны ли твои выводы.
VD>>BCL практически полностью реализован в Моно. Как в прочем и в Роторе. EC>Т.е. я могу создавать Serviced Components и хостить их под моно в линухе?
Serviced Components никогда не входило в состав BCL. Более того Serviced Components — это обертка над COM+, который реализован только под Windows 2000+.
EC> И они смогут участвовать в распределённых транзакциях?
Насколько я понимаю для этого можно использовать библиотеки вроде Кибернэйта.
EC>Для тех, кто не читает между строк — основная мысль моего поста такая: большинству пользователей среды не нужен её кастрированный вариант.
Большинству людей не нужен сам Линукс. Что с того?
В общем, еще раз не притягивай за уши вещи к делу не относящиеся. Ява и Моно прекрасно решают проблему компонентрой разработки. А уж применимость их для решения конкретных задач — это отдельный вопрос.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
, так примеров *реальных* агентных > систем (с интеллектуальными агентами внутрях) там приведено не было. Да > и вообще в этой теме, имхо, мало кто рубит.
У меня уже давно выработалась реакция на болтологический бред
маркетологов. Маркетологические статьи обычно наполнены общими фразами,
обещаниями завоевания мира и т.п.
Статьи про агентные системы по моей маркетологической шкале берут 10 из
10. В Рунете я нашел только нелепые примеры про шахматные программы, где
каждая фигура представлена агентом, отсылающим сообщения другим фигурам
и прочей фигней про искусственный интеллект. В Google'е нашел только
полузаброшенные проекты систем управлениями grid-вычислениями и прочим.
Реальных success stories с агентами что-то не очень видно.
_rasta wrote: > ну... собственно консолью и обеспечиваем, нет? > find /usr/src/linux -name "*.c" -exec grep -H "fuck" {} \; | wc -l > чем не интерактивность? > с другой стороны. что для этого предлагает КОМ? таки да, компонентность > есть, но... а где интерактивность?
Смотри Monad Shell
Здравствуйте, Cyberax, Вы писали:
C>У меня уже давно выработалась реакция на болтологический бред C>маркетологов. Маркетологические статьи обычно наполнены общими фразами, C>обещаниями завоевания мира и т.п.
+1
C>Статьи про агентные системы по моей маркетологической шкале берут 10 из C>10. В Рунете я нашел только нелепые примеры про шахматные программы, где C>каждая фигура представлена агентом, отсылающим сообщения другим фигурам C>и прочей фигней про искусственный интеллект. В Google'е нашел только C>полузаброшенные проекты систем управлениями grid-вычислениями и прочим.
C>Реальных success stories с агентами что-то не очень видно.
Реальные success stories есть, только для агентных систем, которые построены не на интеллектуальных агентах, а на совсем других
. В частности, у нас в компании работает несколько систем, написанных на агентах. Только маркетологического шума мы пока поэтому поводу не упели поднять , так, легкий шумок
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Прежде чем читать этот ответ, предлагаю тебе освежить в памяти текст сообщения, на которое я отвечал, а то ты опять начнёшь отвечать на, то о чём речь и близко не шла.
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 системах развернется.
Я выразил сомнение в том факте, что моно когда-либо развернётся на юнихах, так же как под виндой, про компонентный подход в линукс вообще ни слова.
Но тут пришёл ты, со своей туманной философией, странно ещё, что про Nemerle ничего не сказал.
Т.е. я, например, не верю, что можно завести RSDN@home под моно на линухе и дело даже не в отсутствии Jet.
Думаю с этим ты спорить не будешь?
В общем все твои посты, не относящиеся к теме того поста, на который я отвечал я буду просто скипать.
eao197 wrote: > C>Реальных success stories с агентами что-то не очень видно. > Реальные success stories есть, только для агентных систем, которые > построены не на интеллектуальных агентах, а на совсем других > <http://rsdn.ru/forum/?mid=1570455>
. В частности, у нас в компании > работает несколько систем, написанных на агентах. Только > маркетологического шума мы пока поэтому поводу не упели поднять , так, > легкий шумок
У вас скорее немного другое — система создания message-driven приложений.
В принципе, в мире оно Java уже существует в виде JMS и EJB MDB. JMS
предоставляет очереди сообщений и/или систему subscriber/publisher, а
EJB-контейнер — распределенность, многопоточность и управление контекстом.
Хотя JMS делает ставку скорее на надежность, а не на скорость и обычно
предназначена для распределенного использования.
PS: интересно, а можно ли прикрутить SObjectiser к ActiveMQ? У ActiveMQ
есть C-шный интерфейс и общий результат может получится интересным.
Mamut wrote: > C>Сравни сложность разработки — распределенные приложения заметно сложнее > C>отлаживать и писать. > А как же Эрланг?
Самый правильный вариант Но все равно сложно.
Здравствуйте, Kolhoz, Вы писали:
K> Ещё одна легкоузнаваемая по полёту птица, не врубившаяся в тему. Право слово, смешно-с.
Товарищ Колхозник, я понимаю что я еще молод и мало у меня опыта, и по сравнению с Вами, с гуру, мне не тягаться, а мне и не надо тягаться, всего то я хотел узнать про КОП в линукс мире, я начал изучать линукс, и даже что то под него писать, понимаете я щас под виндами работаю над очень большим проектом, и не могу себе представить проект такого уровня без КОП, мне стало жутко интересно, как же в линуксе писать такие проекты, я стал искать, нашел нечто похожее в XPCOM. Просто у меня возникает некое такое чувство, что под линуксом не так уж и хорошо с КОП, ибо мало больших проектов, и то все в основном с таким ужасным количеством багов. Но не в этом суть, просто меня тошнит от манеры вашего ведения беседы (которое и беседой не назвать). Примерно то же самое видел в linuxforum.ru. Отныне буду просто игнорировать ваши сообщения.
Я очень уважаю Линуса, очень толковый человек, говорит очень правильные на мой взгляд вещи, но почему у Линукс сообщества такие люди как kolhoznik очень часто встречаются, ведь хоть какой бы ни была ОС, без нормального сообщества оно просто пустое место. Ладно, продолжу свое приключение в удивительный мир линуксов, стараясь не обращать внимания на таких людей как колхозник.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Kisloid wrote:
> Вот мне очень интересно. Есть ли под линуксами компонентно > ориентированное программирование ? Исходя из личного опыта, не могу себе > представить крупный проект без компонентно ориентированного подхода. Под > windows например COM, .NET. Знаю под линуксом есть мозилловская > разработка XPCOM. Доводилось с ней работать, но все же она не дотягивает > до COM по качеству, скорости. Может я чего то упустил ?
Мои пять копеек. Имхо идеология Линукс в принципе не озабачивается этим, как операционная система оно не хочет
"ограничивать" пользователей одной технологией, как это делает майкрософт.
Т.е. сама идеология — конструктор "собери-сам", майкрософт же пытается всё запихать в операционку.
Если тебе понадобится выбрать КОП платформу — пожалуйста, java, mono, corba, XPCOM, SOAP, всё что угодно. Линукс —
прежде всего операционная система, притом действительно многоплатформенная.
В общем, Линукс ОС и КОП — вещи перпендикулярые, что хочешь, то прилаживаешь, а КОП в Виндоуз ОС — фактически
неотъемлимая часть.
Спор о том, что более правильное — спор ни о чём, это два решения одной задачи, и оба верные.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
>> Узость мышления. Переключитесь на другую парадигму — и наоборот, >> распределённые системы, построенные на обмене сообщениями будут для вас >> гораздо проще императивных однопоточных последовательных систем. C>Я уже давно понял, что делать распределенные или многопоточные системы C>на чем-то кроме отсылки сообщений — это обычно гиблое дело.
+1
Только понимать тут нечего — это тривиально доказуется формально.
C>В случае с многопоточностью — постоянные проблемы с нужными C>блокировками, а с распределенными системами — проблемы с реакциями на C>сбои. Хотя, конечно, бывают случаи когда обычный RPC намного удобнее.
RPC — это транспортный уровень.
C>Но даже просто системы с отсылкой сообщений все равно сложнее C>отлаживать, хотя бы из-за необходимости следить за несколькими C>приложениями одновременно.
Не сложнее. Для них гораздо лучше развиты формальные методы анализа. А симптоматическая отладка — это вообще зло, её надо искоренять.
Извините за личный вопрос, но не могли бы вы чуть приоткрыть маску? По вашим постам складывается впечатление, что вы являетесь аспирантом в каком-то продвинутом профильном ВУЗе (об этом говорит, например, опыт общения с LaTeX (в том числе и по набору формул), упоминание использования пакета Matematica, теперь вот упоминания про формальные доказательства и теоритические обоснования).
Я спрашиваю потому, что у меня есть некоторый негативный опыт общения с полностью анонимными участниками форума (у которых за ником вообще невозможно различить реального человека). Неприятной особенностью таких персонажей является склонность к весьма серьезным заявлениям и черезмерная категоричность в суждениях. Что в конце-концов резко снижает ценность их сообщений (даже при наличии в них актуальной информации).
Конечно я не в праве просить от вас подобных сведений, но все же если бы вы чуть рассказали о себе (например, образование, наличие/отсутсвие ученых степеней, предметные области, в которых вам доводилось работать), то это позволило бы лично мне определить уровень доверия к вашим высказываниям. Не обижайтесь, пожалуйста, ничего личного.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Абсолютно с тобой согласен. Как раз к такому выводу я и начинал склоняться, особенно после слов Линуса которые я недавно от него услышал. Что то примерно такое: "ОС служит лишь для запуска программ, ОС сама по себе пользователям не нужна, им нужны программы. ОС должна обеспечивать хорошую API для программистов". Это то что, мне запомнилось.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kolhoz, Вы писали:
K> Вы, товарищ, не влезайте в тему которой не понимаете. Я про агентные протоколы говорю. А вы опять со своими примитивными RPC.
[. . .]
K> Это RPC и к теме не относится. Тем более что у жабистов нет ничего сравнимого с другим, гораздо более правильным примитивным RPC — MPI. Так что уж как раз кластерами хвастаться — стыдно.
Уважаемый товарищ Колхоз, в Ваших сообщениях присутствует рационалное зерно, но их общая тональность является совершенно неприемлемой. Лично у меня подобный тон вызывает негативные ассоциации, а именно, ассоциации с персонажем из песни группы "Х.Забей". "Я себя *удаком не считаю, я напротив конкретно продвинутый...". Поэтому, было бы конструктивно прикрутить фитилек, чтобы не коптил. При условии сохранения информативной составляющей сообщений.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
E>Извините за личный вопрос, но не могли бы вы чуть приоткрыть маску? По вашим постам складывается впечатление, что вы являетесь аспирантом в каком-то продвинутом профильном ВУЗе (об этом говорит, например, опыт общения с LaTeX (в том числе и по набору формул), упоминание использования пакета Matematica, теперь вот упоминания про формальные доказательства и теоритические обоснования).
Нет, аспирантство давно закончилось. И latex я применял не только в ВУЗе, а ещё когда работал в науке (в том институте все, включая секретарш, использовали latex — своеобразный такой корпоративный стандарт и богатые традиции).
E>Я спрашиваю потому, что у меня есть некоторый негативный опыт общения с полностью анонимными участниками форума (у которых за ником вообще невозможно различить реального человека). Неприятной особенностью таких персонажей является склонность к весьма серьезным заявлениям и черезмерная категоричность в суждениях. Что в конце-концов резко снижает ценность их сообщений (даже при наличии в них актуальной информации).
Грешен, грешен, допускаю иногда категоричность в экспериментальных целях — посмотреть реакцию оппонентов. Но тут стараюсь этого избегать, нервные все какие-то, самые нейтральные темы вызывают бурю эмоций. Заговоришь о применении дао unix way в программировании под Windows — как сразу кричат про linux на десктопах и про то что windows рулит, хоть это к теме и не относится. Странные люди. Не освоился я тут ещё, в общем.
E>Конечно я не в праве просить от вас подобных сведений, но все же если бы вы чуть рассказали о себе (например, образование, наличие/отсутсвие ученых степеней, предметные области, в которых вам доводилось работать), то это позволило бы лично мне определить уровень доверия к вашим высказываниям. Не обижайтесь, пожалуйста, ничего личного.
Образование — физико-математическое, опыт работы — и в академических структурах, и в коммерческих, и в свободном полёте. В основном, конечно же, работа совсем не по специальности, чистое программирование.
А вообще я не понимаю, к чему это? Я избегаю аргументации с позиции авторитета. Я убеждён, что конструктивная дискуссия возможна только с применением объективных аргументов, не зависящих от личностей дискутирующих. То есть — логика и возможность независимой проверки любого утверждения — основа конструктива. А кто эту логику выводит и откуда он утверждения берёт — плевать, если есть возможность обосновать и проверить всё независимо.
Здравствуйте, eao197, Вы писали:
E>Преподавание у аспирантов -- это обычное явление.
Да, но молодые аспиранты которые мне встречались (за исключением одного) были вполне адекватные парни, с опытом коммерческой разработки. У преподавателей обычно по личному наблюдению опыта коммерческой разработки не бывает. И обычно они не очень в курсе тех дел, что происходит в промышленном программировании.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Cyberax, Вы писали:
>> И, да, это часто относят к искусственному интеллекту — но совершенно >> напрасно. Область применения агентной модели гораздо ширшее и глубжее. C>В общем понятно, система представляется набором агентов, обменивающихся C>сообщениями.
Грубо говоря, да. Только это очень грубо. Под это определение и любая ОО-модель попадёт.
>> Особенность протоколов большинства агентных систем в том, что для обмена >> сообщениями используется сложный, часто тьюринг-полный язык. То есть, >> агенты как бы программируют друг друга. Это очень сильно упрощает жизнь >> при разработке сильно распределённых гетерогенных систем. C>В МОРГ!!!!
Это ваш личный негативный опыт.
C>Я работал с такой системой, которая интегрировала две C>enterprise-системы. Для общения использовался SOAP, а для управления C>control-flow — BPEL4j. Типа grid computing и все такое...
Ну так неудачный транспорт и неудачный язык выбраны. Только и всего. А у меня вот транспорт — банальный tcp, уровня выше и не надо, язык — кастрированная по самые гланды Scheme, на основе SISC. И всё работает идеально — разработчики компонент предоставляют API, причём — почти любой, никаких ограничений на дизайн, сшивка осуществляется на уровне агентного языка, всё тривиально, очень нехилое разделение труда и уровня компетенции.
C>И часто проще C>использовать обычные синхронные сетевые вызовы (что в итоге и произошло C>- осталось несколько веб-сервисов, склеивающих две системы, все C>остальное было написано в обычно стиле).
А это повышает требования к разработчикам компонент. Фтопку.
C>Ну как бы Java не создавалась для high-perf computing. Поэтому сейчас C>Sun и делает Fortress.
, так примеров реальных агентных систем (с интеллектуальными агентами внутрях) там приведено не было. Да и вообще в этой теме, имхо, мало кто рубит.
Специфика. Это обычно rocket science полнейший. Штучные разработки, такими не делятся. Я вот не смогу сослаться ни на одну из агентных систем, в разработке которых принимал участие...
Просто отрасль очень молодая.
Хотя, во многих проектах элементы технологии применяются, и разработчики часто даже не знают, что используют именно агентную модель. У любителей Tcl такое случается сплошь и рядом.
Здравствуйте, eao197, Вы писали:
E>Реальные success stories есть, только для агентных систем, которые построены не на интеллектуальных агентах, а на совсем других
Это нормально Пару месяцев наблюдения за/участия в, и с человеком происходит одно из двух:
— или подсаживается на Священные войны, как наркоман, и сам будешь кричать на всех направо и налево
— или спокойно начинает наблюдать за баталиями, похихикивая над оппонентами, и выискивая в бурных спорах крупицы истины (увлекательнейшее занятие, скажу)
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Kolhoz wrote: > C>В общем понятно, система представляется набором агентов, обменивающихся > C>сообщениями. > Грубо говоря, да. Только это очень грубо. Под это определение и любая > ОО-модель попадёт.
Вот мне и интересно чем оно все так круто.
> C>Я работал с такой системой, которая интегрировала две > C>enterprise-системы. Для общения использовался SOAP, а для управления > C>control-flow — BPEL4j. Типа grid computing и все такое... > Ну так неудачный транспорт и неудачный язык выбраны. Только и всего.
Честно говоря, мне уже давно плевать на чем я пишу. Я могу и на VBA без
проблем писать. Такое состояние возникает когда знаешь примерно 15-20
языков.
Проблемы в том проекте возникали из-за того, что в реальном мире
существуют разделяемые ресурсы. В частности база данных.
Например, ситуация — клиент делает запрос (асинхронный, синхронный —
неважно), сервер создает транзакцию, меняет что-то в базе данных и
отсылает ответ. Вопрос: коммитить ли транзакцию во время отсылки
сообщений (кстати, сразу же становятся необходимы XA-транзакции)?
В некоторых случаях приходилось делать транзакцию длиной в несколько
запросов (делать statefull-узел), в некоторых случаях надо было чтобы
клиент подтвердил получение сообщения, и только после этого коммитить
транзакцию.
В общем, получались _ооочень_ интересные задачи распределенного
программирования.
И все приходилось делать руками. Так как SOAP — это очень базовая вещь,
а всякие WS-Transaction и WS-Security — "сынок, это фантастика".
> C>И часто проще > C>использовать обычные синхронные сетевые вызовы (что в итоге и произошло > C>- осталось несколько веб-сервисов, склеивающих две системы, все > C>остальное было написано в обычно стиле). > А это повышает требования к разработчикам компонент. Фтопку.
Наоборот, понижает. Так как разработчикам не нужно уметь писать
распределенные алгоритмы — они просто пишут старый добрый синхронный код.
Здравствуйте, Kisloid, Вы писали:
K>Товарищ Колхозник, я понимаю что я еще молод и мало у меня опыта, и по сравнению с Вами, с гуру, мне не тягаться, а мне и не надо тягаться, всего то я хотел узнать про КОП в линукс мире, я начал изучать линукс, и даже что то под него писать, понимаете я щас под виндами работаю над очень большим проектом, и не могу себе представить проект такого уровня без КОП, мне стало жутко интересно, как же в линуксе писать такие проекты, я стал искать, нашел нечто похожее в XPCOM.
Похвально. Вот и попробуйтесь врубиться в это простое и очень гибкое дао — unix way.
Вы же, по вашему выбору сообщений, на которые вы отвечаете, такой попытки явно и не сделали.
K> Просто у меня возникает некое такое чувство, что под линуксом не так уж и хорошо с КОП, ибо мало больших проектов, и то все в основном с таким ужасным количеством багов.
Чушь говоришь. Подавляющее большинство больших проектов делается в рамках unix way. Я не видел success stories по настоящему крупных систем на DCOM.
K> Но не в этом суть, просто меня тошнит от манеры вашего ведения беседы (которое и беседой не назвать). Примерно то же самое видел в linuxforum.ru. Отныне буду просто игнорировать ваши сообщения.
Ты научись сначала понимать, что люди говорят. Ты же русским языком не владеешь! И эта конкретная ветка — тому пример. Я про одно — а ты и подпевалы — совсем про другое. Даже умудрился где-то углядеть якобы "презрение к пользователям Windows".
Вот например — с какого перепуга ты меня в пользователи linux записал, а?!? Кто тебе дал такое право? Я хоть словом об этом обмолвился? Наоборот, я постоянно настаиваю на применении концепций unix way под windows. Но ты ж читать не умеешь, куда тебе до таких тонкостей опускаться.
Здравствуйте, Kolhoz, Вы писали:
K>Вы же, по вашему выбору сообщений, на которые вы отвечаете, такой попытки явно и не сделали.
K> Чушь говоришь. Подавляющее большинство больших проектов делается в рамках unix way. Я не видел success stories по настоящему крупных систем на DCOM.
А причем тут распределенки ?
K> Ты научись сначала понимать, что люди говорят. Ты же русским языком не владеешь! И эта конкретная ветка — тому пример. Я про одно — а ты и подпевалы — совсем про другое. Даже умудрился где-то углядеть якобы "презрение к пользователям Windows".
Ничего личного, но мнение "некоторых" мягко сказать меня не интересует вовсе. Я все понимаю. здесь
смотри последнюю свою фразу. Вообще совутею вам немного оглядываться назад, попытаться посмотреть на себя со стороны. Говорят помогает
K> Вот например — с какого перепуга ты меня в пользователи linux записал, а?!? Кто тебе дал такое право? Я хоть словом об этом обмолвился? Наоборот, я постоянно настаиваю на применении концепций unix way под windows. Но ты ж читать не умеешь, куда тебе до таких тонкостей опускаться.
А ну от опять пошло поехало: "куда уж тебе, до такого Великого Гуру как Я..."
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Kolhoz wrote: > K> Просто у меня возникает некое такое чувство, что под линуксом не так > уж и хорошо с КОП, ибо мало больших проектов, и то все в основном с > таким ужасным количеством багов. > Чушь говоришь. Подавляющее большинство больших проектов делается в > рамках unix way. Я не видел success stories по настоящему крупных систем > на DCOM.
Могу рассказать.
Для работы в замкнутой контролируемой среде он вполне подходит. Особенно
если учесть, что еще есть MS DTC, который очень помогает при разработке
enterprise-приложений (Помогает по сравнению с отутствием себя,
естественно. Сейчас есть более нормальные альтернативы).
> Ты научись сначала понимать, что люди говорят. Ты же русским языком не > владеешь! И эта конкретная ветка — тому пример. Я про одно — а ты и > подпевалы — совсем про другое. Даже умудрился где-то углядеть якобы > "презрение к пользователям Windows".
Было, было. В частности про виндузятников с узким кругозором.
Здравствуйте, McSeem2, Вы писали:
K>> Это RPC и к теме не относится. Тем более что у жабистов нет ничего сравнимого с другим, гораздо более правильным примитивным RPC — MPI. Так что уж как раз кластерами хвастаться — стыдно.
MS>Уважаемый товарищ Колхоз, в Ваших сообщениях присутствует рационалное зерно, но их общая тональность является совершенно неприемлемой. Лично у меня подобный тон вызывает негативные ассоциации, а именно, ассоциации с персонажем из песни группы "Х.Забей". "Я себя *удаком не считаю, я напротив конкретно продвинутый...". Поэтому, было бы конструктивно прикрутить фитилек, чтобы не коптил. При условии сохранения информативной составляющей сообщений.
Откровенно говоря твой тон, в данном случае, мне больше не нравится. Нельзя ли без этих гопнических мотивов?
В следующий раз за такое "предостирижение" пойдешь в баню. Так что или пиши их приватом, или соблюдай приличие.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kolhoz, Вы писали:
K> Ты научись сначала понимать, что люди говорят. Ты же русским языком не владеешь! И эта конкретная ветка — тому пример. Я про одно — а ты и подпевалы — совсем про другое. Даже умудрился где-то углядеть якобы "презрение к пользователям Windows".
Просьба, без наездов на окружающий и без аппеляции к их владению русским и т.п.
И вообще, сбавь обороты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kan_izh, Вы писали:
_>Если тебе понадобится выбрать КОП платформу — пожалуйста, java, mono, corba, XPCOM, SOAP, всё что угодно.
...
_>В общем, Линукс ОС и КОП — вещи перпендикулярые, что хочешь, то прилаживаешь, а КОП в Виндоуз ОС — фактически _>неотъемлимая часть.
Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что угодно" не приминимы? Если "да", то откровенно говоря закрыдываются сомнения на счет твоего знания Виндовс. Если "нет" (т.е. применимы), тогда закрадывается сомнение в честности высказывания.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kolhoz, Вы писали:
K> А вообще я не понимаю, к чему это?
Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности). Как правило, такие люди очень не желают рассказывать о том, чем им приходилось заниматься и над чем они работают сейчас.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности). Как правило, такие люди очень не желают рассказывать о том, чем им приходилось заниматься и над чем они работают сейчас.
Вообще-то это не только не итично, но и еще п.5 по совместительству.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Kolhoz, Вы писали:
K>> А вообще я не понимаю, к чему это?
E>Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности).
А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.
Здравствуйте, Cyberax, Вы писали:
>> Ну так неудачный транспорт и неудачный язык выбраны. Только и всего. C>Честно говоря, мне уже давно плевать на чем я пишу.
Конечно плевать. Ты то живой. А вот на чём пишет агент — не плевать. Тупой он очень. Ему что попроще надо.
C> Я могу и на VBA без C>проблем писать. Такое состояние возникает когда знаешь примерно 15-20 C>языков.
Ну я их побольше 20 знаю. Но мне не плевать на чём писать. Я постараюсь выбрать тот язык, который под конкретную задачу наиболее подходит. Случается, что и VBA выбираю. Но для языка общения агентов я точно ничего бейсикоподобного не выберу.
C>Проблемы в том проекте возникали из-за того, что в реальном мире C>существуют разделяемые ресурсы. В частности база данных.
Проблемы возникают если про эти разделяемые ресурсы забывают при проектировании, думая, что "фигня, потом приковыряем".
C>Например, ситуация — клиент делает запрос (асинхронный, синхронный — C>неважно), сервер создает транзакцию, меняет что-то в базе данных и C>отсылает ответ. Вопрос: коммитить ли транзакцию во время отсылки C>сообщений (кстати, сразу же становятся необходимы XA-транзакции)?
Завернуть обработку транзакций в одного атомарного агента, который будет с остальным миром общаться на более высоком уровне. Всего делов. Никто другой соединений иметь не будет. Ресурс перестал быть разделяемым.
C>В некоторых случаях приходилось делать транзакцию длиной в несколько C>запросов (делать statefull-узел), в некоторых случаях надо было чтобы C>клиент подтвердил получение сообщения, и только после этого коммитить C>транзакцию.
Угу. И так можно.
C>В общем, получались _ооочень_ интересные задачи распределенного C>программирования.
Что же тут интересного? Чем БД от любого другого агента отличается? У каждого агента есть состояние, часто — транзакционное, с возможностью отката.
C>И все приходилось делать руками. Так как SOAP — это очень базовая вещь, C>а всякие WS-Transaction и WS-Security — "сынок, это фантастика".
Ну уж на уровне транспорта программировать — и вовсе изврат. Я этого SOAP наелся столько, когда реализацию ebXML (messaging) делал, что больше его видеть не желаю.
>> А это повышает требования к разработчикам компонент. Фтопку. C>Наоборот, понижает. Так как разработчикам не нужно уметь писать C>распределенные алгоритмы — они просто пишут старый добрый синхронный код.
Гы. В моём варианте им вообще не надо распределённые алгоритмы писать. Они делают компоненты, а сшивка делается на стороне.
Здравствуйте, Kisloid, Вы писали:
K>> Чушь говоришь. Подавляющее большинство больших проектов делается в рамках unix way. Я не видел success stories по настоящему крупных систем на DCOM.
K>А причем тут распределенки ?
Мы же про крупные системы говорим, так? Или у нас разные представления о том, что есть крупная система.
K>здесь
смотри последнюю свою фразу. Вообще совутею вам немного оглядываться назад, попытаться посмотреть на себя со стороны. Говорят помогает
И что же тут не так? Наблюдение моё совершенно объективное. Сторонники genuine windows way любой разговор про КОП сводят к документам и оффисам. Что характерно, сторонники unix way об этом классе задач обычно вообще не думают, он им не интересен. Гораздо более крупными системами занимаются, вестимо.
K>> Вот например — с какого перепуга ты меня в пользователи linux записал, а?!? Кто тебе дал такое право? Я хоть словом об этом обмолвился? Наоборот, я постоянно настаиваю на применении концепций unix way под windows. Но ты ж читать не умеешь, куда тебе до таких тонкостей опускаться.
K>А ну от опять пошло поехало: "куда уж тебе, до такого Великого Гуру как Я..."
Вот опять пошло-поехало — ты опять ну ни хрена не понял. Ни единого слова. Скажи, у тебя дислексия, да? Вот расскажи мне, например, как ты понимаешь смысл термина "семантика". В контексте лингвистики. Надо же докопаться до сути — почему ты абсолютно не в состоянии адекватно воспринимать информацию, изложенную на вроде бы родном тебе русском языке.
Здравствуйте, Cyberax, Вы писали:
>> Ты научись сначала понимать, что люди говорят. Ты же русским языком не >> владеешь! И эта конкретная ветка — тому пример. Я про одно — а ты и >> подпевалы — совсем про другое. Даже умудрился где-то углядеть якобы >> "презрение к пользователям Windows". C>Было, было. В частности про виндузятников с узким кругозором.
Из контекста было совершенно ясно, что виндузятники — это сторонники genuine windows way. Простых смертных юзеров мы в разговоре вообще не касались. А кругозор ведь и в самом деле узкий — о чём ни начинай разговор, а всё документами закончится. Это, собственно, windows way и есть — всё есть документ, а что не документ, то папочка, и вообще, закройте глаза, дышите глубже, представьте себе тяжелый кондовый такой конторский стол... Представили? Медитируйте на него!
Здравствуйте, Kolhoz, Вы писали:
K> И что же тут не так? Наблюдение моё совершенно объективное. Сторонники genuine windows way любой разговор про КОП сводят к документам и оффисам. Что характерно, сторонники unix way об этом классе задач обычно вообще не думают, он им не интересен. Гораздо более крупными системами занимаются, вестимо.
А чем измеряется крупность системы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, Kolhoz, Вы писали:
K>>> А вообще я не понимаю, к чему это?
E>>Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности).
K> А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.
Здравствуйте, Kolhoz, Вы писали:
K> А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.
Видите, с какими противоположными взглядами здесь общаются люди. Если мне школьник скажет, что на небе 102346234846 звезд, то для меня это будет совершенно непроверенная информация. Если же это число скажет профессор-астроном, то я с большой вероятности приму это значение на веру. Хотя бы потому, что я могу сослаться на этого профессора. Или же описание механизма исключений в C++ я предпочту прочитать в книге Страуструпа, а не в "Освой C++ самостоятельно за 21 день".
Кстати, анекдот в тему:
Беседуют два профессора. Один говорит:
-- Вы представляете, коллега, если сказать кому-нибудь, что на небе 102346234846 звезд, то 99.9% людей в это тут же поверят. А вот стоит повесить на скамейку табличку "Осторожно, окрашено", то все обязательно будут проверять это пальцем.
Извините, если мой вопрос показался вам не корректным. Давно я уже тут, параноя, знаете ли
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2 wrote:
> _>Если тебе понадобится выбрать КОП платформу — пожалуйста, java, mono, > corba, XPCOM, SOAP, всё что угодно. > _>В общем, Линукс ОС и КОП — вещи перпендикулярые, что хочешь, то > прилаживаешь, а КОП в Виндоуз ОС — фактически > _>неотъемлимая часть. > Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что > угодно" не приминимы? Если "да", то откровенно говоря закрыдываются > сомнения на счет твоего знания Виндовс. Если "нет" (т.е. применимы), > тогда закрадывается сомнение в честности высказывания.
Применимы. Но это заслуга этих технологий, а не винды.
Ты так и не понял о чём я. Винда — набор "всё в одном". Ставишь винду — получаешь сразу всё, хотя не всегда лучшего
качества и не всегда адекватного. Линух — конструктор "собери сам", собираешь по своему вкусу, требованиям, железу.
В винду встроено COM+, и отключить его просто так не получится, тебе оно навязано. А некоторые дистрибы линуха вполне
могут содержать какую-нидь КОП платформу, на которой дистриб построен (та хрень в KDE, например), но это не входит как
неотъемлемая часть в линух вообще.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Kolhoz wrote: > C>Проблемы в том проекте возникали из-за того, что в реальном мире > C>существуют *разделяемые ресурсы*. В частности база данных. > Проблемы возникают если про эти разделяемые ресурсы забывают при > проектировании, думая, что "фигня, потом приковыряем".
Если бы учли их сразу — то не писали бы в виде агентов.
> Завернуть обработку транзакций в одного атомарного агента, который будет > с остальным миром общаться на более высоком уровне. Всего делов. Никто > другой соединений иметь не будет. Ресурс перестал быть разделяемым.
А вот фига. Базу и так уже можно считать агентом, который отвечает на
запросы по некоторому протоколу. Проблема с семантикой работы с данными
в БД.
> Что же тут интересного? Чем БД от любого другого агента отличается? У > каждого агента есть состояние, часто — транзакционное, с возможностью > отката.
Проблема в том, что разные клиенты могут видеть разное состояние БД
в зависимости от своего транзакционного состояния и состояния остальных клиентов. А еще в жестоком реальном мире есть триггеры
в БД, хранимые процедуры и нарушения constraint'ов.
Более того, у БД нет цельного состояния — ее корректно можно
моделировать в агентской парадигме только если считать каждую строку
отдельным агентом.
> C>И все приходилось делать руками. Так как SOAP — это очень базовая вещь, > C>а всякие WS-Transaction и WS-Security — "сынок, это фантастика". > Ну уж на уровне транспорта программировать — и вовсе изврат.
Опять же, работа идет не на уровне транспортов, а на уровне сервисов. Скажем, EJB-контейнер предоставляет управляемым бинам
(bean) контролируемое окружение. Сам контейнер обеспечивает безопасность
(через систему principal'ов), подключает необходимые сервисы, позволяет
декларативно задавать транзакции.
Это все может казаться простым и тривиальным, но корректно это все
реализовать очень непросто.
> C>Наоборот, понижает. Так как разработчикам не нужно уметь писать > C>распределенные алгоритмы — они просто пишут старый добрый синхронный код. > Гы. В моём варианте им вообще не надо распределённые алгоритмы писать. > Они делают компоненты, а сшивка делается на стороне.
Алгоритмы становятся распределенными, если между ними есть разделяемое
состояние (база данных).
Здравствуйте, Дарней, Вы писали:
Д>а поясни мне плиз, какое отношение наличие в Моно поддержки EnterpriseServices имеет к компонентности Моно?
Поясняю — никакого.
Я компонентность Моно не обсуждал — читай внимательнее ту часть сообщения
Здравствуйте, kan_izh, Вы писали:
>> Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что >> угодно" не приминимы? Если "да", то откровенно говоря закрыдываются >> сомнения на счет твоего знания Виндовс. Если "нет" (т.е. применимы), >> тогда закрадывается сомнение в честности высказывания. _>Применимы.
Значит делаем вывод в нечестности, ну, или хотя бы в ошибочности твоих высказываний.
_> Но это заслуга этих технологий, а не винды.
Что это тебя так перекосило? Уж не угледел ли ты чего остроумного в своих словах?
Уж не заслуга ли Линукс в том, что эти технологии работают и на нем тоже?
_>Ты так и не понял о чём я.
Возможно. Но понял, что суждения твои крейне противоречивы и ошибочны.
_> Винда — набор "всё в одном". Ставишь винду — получаешь сразу всё, хотя не всегда лучшего качества и не всегда адекватного. Линух — конструктор "собери сам", собираешь по своему вкусу, требованиям, железу.
Высосанное из пальца утверждение. Если конечно не брать в рассчет, что можно заняться самостятельным потчиньем ядра.
Я имею под Виндовс все то что под Линукс и немного больше. Обратное не верно. А раз так, то все что можно сказать об линуксе можно сказать и о Виндовс.
_>В винду встроено COM+, и отключить его просто так не получится, тебе оно навязано.
Начнем с того, что есть встраиваемыме версии Виндовс в которых ни КОМ-а, ни даже графической оболочки нет. Так что это твое незнание проблемы говорит. Виндовс на КОМ не основана. Он в ней часто применяется как средство абстракции и компонентизации, но и только.
Ну, и главное. Что собственного плохого в наличии КОМ? Вот его отсуствие является для многих минусом.
_> А некоторые дистрибы линуха вполне _>могут содержать какую-нидь КОП платформу, на которой дистриб построен (та хрень в KDE, например), но это не входит как _>неотъемлемая часть в линух вообще.
И что? Какое это отношение имеет к делу и к откоровенно неверным и мягко говоря лукавым заявлениям сделанным тобой выше?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности). Как правило, такие люди очень не желают рассказывать о том, чем им приходилось заниматься и над чем они работают сейчас.
Вообще это называется апелляцией к опыту. Коя есть некорректный приём и так далее.
<< Под музыку: Zebda — La cucaracha >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Kolhoz, Вы писали:
K>>> А вообще я не понимаю, к чему это?
E>>Все очень просто, хочется понять, стоит ли за ником реальный специалист или же пустой трепач, на слова которого не стоит обращать внимания и тратить свое время (или вообще не адекватные личности).
K> А вот мне всегда абсолютно всё равно, с кем я разговариваю, пусть даже он школьник или ПТУшник. Я думаю быстро, времени на оценку много не уходит. А оцениваю исключительно качество объективной аргументации. Если школьник скажет, что 2+2=4 у меня не будет оснований ему не доверять только за то, что он школьник и не имеет коммерческого опыта сложения положительных целых чисел.
я вот почитал про вашу любовь к категоричности и большой любви к логическим доказательствам, на основе которых, как я понял, сформированы и выстроены в четкие логические цепочки все ваши знания, а доказательства которые у вас получилось доказать...... хм... вобщем мне стало любопытно...
А скажите пожалуйста, вы считаете что утверждение 2+2=4 всегда и везде верно? И доказать это можете?
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>>> Весь этот 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?
Играючи. Смотря какая игра, на самом деле.
<< Под музыку: Zebda — La cucaracha >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
C>Я уже давно понял, что делать распределенные или многопоточные системы C>на чем-то кроме отсылки сообщений — это обычно гиблое дело.
Угу. Особенно, если не забывать, что потенциально любой "синхронный" вызов по сети может завершиться исключением.
<< Под музыку: Zebda — La cucaracha >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Геннадий Васильев wrote: > C>Я уже давно понял, что делать распределенные или многопоточные системы > C>на чем-то кроме отсылки сообщений — это обычно гиблое дело. > Угу. Особенно, если не забывать, что потенциально любой "синхронный" > вызов по сети может завершиться исключением.
Ну это вполне нормально — в определенных случаях.
Например, в EJB-контейнерах для компонентов обеспечивается
контролируемое окружение, и если что-то там прилетит неправильное —
контейнер все аккуратно откатит и скажет, что так и было
VladD2 wrote: > Я имею под Виндовс все то что под Линукс и немного больше. Обратное не > верно. А раз так, то все что можно сказать об линуксе можно сказать и о > Виндовс.
А Reiser4FS на Винде есть? Или любая другая нормальная FS, которая не
торомзит?
Геннадий Васильев wrote: > Не совсем так. Unix way (во всяком случае, в контексте этой дискуссии, > как я её понимаю) не так мёртво завязан на синхронность вызовов. Что > COM, что CORBA — одна и та же песня: синхронный вызов с непредсказуемой > длительностью, с помощью которых ещё и эмулировать messaging приходится.
Ну так и запись в пайп — блокирующееся операция, причем еще можно и
SIGPIPE'ом в морду получить.
> Опять таки, любой вызов DCOM/CORBA может завершиться исключением, а это > уже требует в обязательном порядке обкладывать их обработкой исключений, > с messaging всё проще — мы сразу честно признаёмся себе, что > длительность вызова предсказать нельзя и ориентируемся на модель: "ждём > сообщение", а не "должно сработать!".
Ну так и с синхронными вызовами это возможно. Просто сразу говорим, что
методы могут работать неограниченно долго.
> А простой messaging по IP: сокеты плюс > простенькая сериализация. Да и то, в случае C можно структуры данных > почти без изменений гонять (диспетчеризация только нужна и решение > конфликта endian-ов).
Простой-то, он простой. Да вот сильно ненадежный.
Например, сейчас работаем с заказчиком в USA — канал связи до него
паршивый. Обычное сокетное соедиенение падает где-то раз в час (из-за
чего работать через SSH особенно удобно), так что необходимы механизмы
восстановления после сбоев, а это уже не так-то и просто сделать. А если
еще failover захочется...
Здравствуйте, Cyberax, Вы писали:
C>Ну так и запись в пайп — блокирующееся операция, причем еще можно и C>SIGPIPE'ом в морду получить.
Если мне не отшибает память, то SIGPIPE можно получить в Unix-е и при попытке записи в закрытый сокет (или чтения из закрытого сокета, не помню точно).
C>Ну так и с синхронными вызовами это возможно. Просто сразу говорим, что C>методы могут работать неограниченно долго.
Насколько я знаю, неограничено долго RPC вызовы не работают. Они завершаются либо с кодом ошибки TIMEOUT или с порождением такого же исключения.
>> А простой messaging по IP: сокеты плюс >> простенькая сериализация. Да и то, в случае C можно структуры данных >> почти без изменений гонять (диспетчеризация только нужна и решение >> конфликта endian-ов). C>Простой-то, он простой. Да вот сильно ненадежный.
C>Например, сейчас работаем с заказчиком в USA — канал связи до него C>паршивый. Обычное сокетное соедиенение падает где-то раз в час (из-за C>чего работать через SSH особенно удобно), так что необходимы механизмы C>восстановления после сбоев, а это уже не так-то и просто сделать.
Это восстановление IP-соединения сложно сделать?
Да элементарно все делается. Даже в книгах по ACE, если не ошибаюсь, приводятся примеры того, как восстанавливать TCP/IP подключения после сбоев. И как строить приложения на основе нескольких слоев, чтобы подобные разрывы и восстановления связи не оказывали на приложение влияния.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > C>Ну так и запись в пайп — блокирующееся операция, причем еще можно и > C>SIGPIPE'ом в морду получить. > Если мне не отшибает память, то SIGPIPE можно получить в Unix-е и при > попытке записи в закрытый сокет (или чтения из закрытого сокета, не > помню точно).
Да, или в закрытый pipe (как ни странно).
А закрытым он может стать из-за потери связи, например.
> Насколько я знаю, неограничено долго RPC вызовы не работают. Они > завершаются либо с кодом ошибки TIMEOUT или с порождением такого же > исключения.
Для почти всех практических целей таймаут в две минуты — неограниченно
долго
> C>Простой-то, он простой. Да вот сильно ненадежный. > C>Например, сейчас работаем с заказчиком в USA — канал связи до него > C>паршивый. Обычное сокетное соедиенение падает где-то раз в час (из-за > C>чего работать через SSH особенно удобно), так что необходимы механизмы > C>восстановления после сбоев, а это уже не так-то и просто сделать. > Это восстановление IP-соединения сложно сделать?
Восстановление — никак. Пересоединение — можно.
> Да элементарно все делается. Даже в книгах по ACE, если не ошибаюсь, > приводятся примеры того, как восстанавливать TCP/IP подключения после > сбоев. И как строить приложения на основе нескольких слоев, чтобы > подобные разрывы и восстановления связи не оказывали на приложение влияния.
Не так все просто. А если сервер перегружен и из-за этого по таймауту
отваливается? Тогда неплохо бы переключиться на резервный сервер, но
только если для сессии не установлен sticky-marker. А stateless-вызовы
можно load ballancing'ом распределять между серверами.
А еще есть failure modes, когда клиент обрабатывает сообщение, отсыла
VladD2 wrote: > Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что > угодно" не приминимы? Если "да", то откровенно говоря закрыдываются > сомнения на счет твоего знания Виндовс.
Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM.
> Если "нет" (т.е. применимы), > тогда закрадывается сомнение в честности высказывания.
Вероятно, имелось в виду, что определенная реализация КОП уже намертво
защита в Винду.
Здравствуйте, Cyberax, Вы писали:
>> Не совсем так. Unix way (во всяком случае, в контексте этой дискуссии, >> как я её понимаю) не так мёртво завязан на синхронность вызовов. [...] C>Ну так и запись в пайп — блокирующееся операция, причем еще можно и C>SIGPIPE'ом в морду получить.
Хм... Вообще-то — да. Что-то меня на сокетах заклинило.
>> [...] ориентируемся на модель: "ждём сообщение", а не "должно сработать!". C>Ну так и с синхронными вызовами это возможно. Просто сразу говорим, что C>методы могут работать неограниченно долго.
+1
>> А простой messaging по IP [...] C>Простой-то, он простой. Да вот сильно ненадежный.
+1 Я просто попробовал выделить основные моменты в Unix way и в вольно пояснить, почему messaging — базовый механизм по отношению к RPC.
PS.: Нет, не правильное это дело — объяснять Дао.
<< Под музыку: Zebda — La cucaracha >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
C>А закрытым он может стать из-за потери связи, например.
Кстати, такие проблемы снимаются как только начинаешь работать с сокетом через предварительный select для определения статуса.
>> Это восстановление IP-соединения сложно сделать? C>Восстановление — никак. Пересоединение — можно.
Ну да, я не точно выразился.
>> Да элементарно все делается. Даже в книгах по ACE, если не ошибаюсь, >> приводятся примеры того, как восстанавливать TCP/IP подключения после >> сбоев. И как строить приложения на основе нескольких слоев, чтобы >> подобные разрывы и восстановления связи не оказывали на приложение влияния. C>Не так все просто. А если сервер перегружен и из-за этого по таймауту C>отваливается? Тогда неплохо бы переключиться на резервный сервер, но C>только если для сессии не установлен sticky-marker. А stateless-вызовы C>можно load ballancing'ом распределять между серверами.
А что такое sticky-marker?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > C>А закрытым он может стать из-за потери связи, например. > Кстати, такие проблемы снимаются как только начинаешь работать с сокетом > через предварительный select для определения статуса.
Тогда надо переписывать код "наизнанку" (или использовать языки с
сontinuation'ами).
> C>Не так все просто. А если сервер перегружен и из-за этого по таймауту > C>отваливается? Тогда неплохо бы переключиться на резервный сервер, но > C>только если для сессии не установлен sticky-marker. А stateless-вызовы > C>можно load ballancing'ом распределять между серверами. > А что такое sticky-marker?
Маркер, означающий, что сессия "прилипает" к определенному серверу и не
может быть переброшена на другие load-ballancing'ом или failover'ом.
Здравствуйте, Cyberax, Вы писали:
>> C>А закрытым он может стать из-за потери связи, например. >> Кстати, такие проблемы снимаются как только начинаешь работать с сокетом >> через предварительный select для определения статуса. C>Тогда надо переписывать код "наизнанку" (или использовать языки с C>сontinuation'ами).
Можно проще -- использовать ACE_Reactor или ACE_Proactor Или похожие собственные схемы.
>> C>Не так все просто. А если сервер перегружен и из-за этого по таймауту >> C>отваливается? Тогда неплохо бы переключиться на резервный сервер, но >> C>только если для сессии не установлен sticky-marker. А stateless-вызовы >> C>можно load ballancing'ом распределять между серверами. >> А что такое sticky-marker? C>Маркер, означающий, что сессия "прилипает" к определенному серверу и не C>может быть переброшена на другие load-ballancing'ом или failover'ом.
Спасибо, понял.
Кстати, с переключением на резервный сервер есть еще одна интересная деталь. Может потребоваться периодически пытатся переподключиться к основному серверу и, если это удалось, соединение с резервным сервером закрыть, а по основному соединение продолжить работу.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2 wrote:
>> > Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что >> > угодно" не приминимы? Если "да", то откровенно говоря закрыдываются >> > сомнения на счет твоего знания Виндовс. Если "нет" (т.е. применимы), >> > тогда закрадывается сомнение в честности высказывания. > _>Применимы. > Значит делаем вывод в нечестности, ну, или хотя бы в ошибочности твоих > высказываний.
Навек позор покрыл меня.
> _> Но это заслуга этих технологий, а не винды. > Что это тебя так перекосило? Уж не угледел ли ты чего остроумного в > своих словах?
Простите, дяденка.
> Уж не заслуга ли Линукс в том, что эти технологии работают и на нем тоже?
Некоторые вещи пишут под линух, под винду портят. Тот же mysql/apache, объявляя, что "оно как-то работает", как никто не
гарантирует...
> _>Ты так и не понял о чём я. > Возможно. Но понял, что суждения твои крейне противоречивы и ошибочны.
Я неудачник, убью себя на досуге.
> _> Винда — набор "всё в одном". Ставишь винду — получаешь сразу всё, > хотя не всегда лучшего качества и не всегда адекватного. Линух — > конструктор "собери сам", собираешь по своему вкусу, требованиям, железу. > Высосанное из пальца утверждение. Если конечно не брать в рассчет, что > можно заняться самостятельным потчиньем ядра.
Собственно, почему не брать? Не укладывается в твою супер-концепцию? Кстати, неплохо бы вспомнить, что винда по этому
пути "гибкости" пошла по необходимости, чтобы противостоять конкуренции. Гибкость линуксов же — by design, с рождения.
> Я имею под Виндовс все то что под Линукс и немного больше. Обратное не > верно. А раз так, то все что можно сказать об линуксе можно сказать и о > Виндовс.
Что "немного больше" (особенно с т.з. сабжа)?
> _>В винду встроено COM+, и отключить его просто так не получится, тебе > оно навязано. > Начнем с того, что есть встраиваемыме версии Виндовс в которых ни КОМ-а, > ни даже графической оболочки нет. Так что это твое незнание проблемы > говорит. Виндовс на КОМ не основана. Он в ней часто применяется как > средство абстракции и компонентизации, но и только.
Если так рассуждать, то в чём тогда сабж?
> Ну, и главное. Что собственного плохого в наличии КОМ? Вот его отсуствие > является для многих минусом.
Вообще говоря, по отношению к сабжу, то, что его считают "правильным" для винды.
> _> А некоторые дистрибы линуха вполне > _>могут содержать какую-нидь КОП платформу, на которой дистриб построен > (та хрень в KDE, например), но это не входит как > _>неотъемлемая часть в линух вообще. > И что? Какое это отношение имеет к делу и к откоровенно неверным и мягко > говоря лукавым заявлениям сделанным тобой выше?
Попробуй порассуждать:
"КОП в винде" — такого вопроса нет. Сразу очевидно = COM, .NET.
"КОП в линух" — вопрос? Да что угодно!
Я ничего не пытаюсь доказать, сказать что правильно, что неправильно. Что плохо, что хорошо. Что верный путь, что
неверный. Просто попытался объяснить, почему вообще такой вопрос в сабже возник.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
eao197 wrote: > C>Тогда надо переписывать код "наизнанку" (или использовать языки с > C>сontinuation'ами). > Можно проще -- использовать ACE_Reactor или ACE_Proactor Или похожие > собственные схемы.
А можно еще Boost.Asio использовать
Все равно придется писать event-driven код.
> Кстати, с переключением на резервный сервер есть еще одна интересная > деталь. Может потребоваться периодически пытатся переподключиться к > основному серверу и, если это удалось, соединение с резервным сервером > закрыть, а по основному соединение продолжить работу.
Еще много чего может быть
Cyberax wrote:
>> Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что >> угодно" не приминимы? Если "да", то откровенно говоря закрыдываются >> сомнения на счет твоего знания Виндовс. > Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM.
И юних вэй — баши, пайпы, грепы, авки, перлы и прочую [гр]адость.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
K> А я вот ни разу от морды не плясал. Всегда плясал от workflow, логики и структур данных. Что я делал не так?
Весьма зря. Прогуглитесь на тему функционально-ориентированных метрик в предварительном планировании. Будете удивлены. И это, кстати, общепризнано и работает. Или что-то более крутое типа COCOMOII
И вообще, в приложении все должно быть таким, чтобы удовлетворяло клиента. И обивка для кресел, и мотор.
Здравствуйте, eao197, Вы писали:
E>Видите, с какими противоположными взглядами здесь общаются люди. Если мне школьник скажет, что на небе 102346234846 звезд, то для меня это будет совершенно непроверенная информация. Если же это число скажет профессор-астроном, то я с большой вероятности приму это значение на веру.
А я на веру ничего принимать не буду. Я попрошу библиографические ссылки, и постараюсь убедиться, что число получено из нескольких независимых источников. И тогда степень довария к этой информации будет довольно большой. Но естественно не 100%, к фактической информации такого довария не может быть никогда просто по определению. И, кстати, чем более важна для меня информация (то есть — если она используется в моих собственных рассуждениях), тем более низкий первоначальный коэффециент доверия она получит, и тем больше усилий по проверке её мне придётся приложить. Так что да, про количество звёзд я приму с высокой степенью доверия хотя бы от того, что мне абсолютно наплевать, сколько их там видно. Мне эта информация совершенно бесполезна.
Вот если мне приведут логическую конструкцию, которую я могу независимо проверить, не зависящую от достоверности каких либо внешних фактов — тогда да, тогда я буду на 100% уверен в корректности утверждения. В случае с 2+2=4 это возможно, в случае с количеством звёзд — нет.
E> Хотя бы потому, что я могу сослаться на этого профессора.
Как сослаться? На трёп ссылаться нельзя. Ссылаться можно на опубликованный результат, прошедший через peer review.
E> Или же описание механизма исключений в C++ я предпочту прочитать в книге Страуструпа, а не в "Освой C++ самостоятельно за 21 день".
Для этого не надо никаких представлений об авторитетах. Достаточно знать, как язык реализуют, какое отношение мнение Страуструпа имеет к решениям комитета, и на кого ориентируются разработчики конкретных реализаций языка. Вся информация открытая и объективная. И авторитетность тут совершенно не при делах.
Здравствуйте, Streamer1, Вы писали:
S>А скажите пожалуйста, вы считаете что утверждение 2+2=4 всегда и везде верно? И доказать это можете?
Когда не указано специально, считается, что применяется аксиоматика целых чисел. Обычно используется аксиоматика Пеано. В её рамках 2+2 всегда будет 4, и это доказывается элементарно. Таковы правила языка — есть набор общепринятых умолчаний. Если же будет сказано, что эта запись — на другом языке, в другой аксиоматике — то это уже будет и совершенно другое утверждение.
Здравствуйте, GlebZ, Вы писали:
K>> А я вот ни разу от морды не плясал. Всегда плясал от workflow, логики и структур данных. Что я делал не так? GZ>Весьма зря. Прогуглитесь на тему функционально-ориентированных метрик в предварительном планировании. Будете удивлены. И это, кстати, общепризнано и работает.
Я как бы в курсе. Ну так ведь тут мы пляшем от ФУНКЦИЙ. От бизнес-процессов, от семантики, а не от внешнего вида морды. Об что, собственно, и спич.
GZ> Или что-то более крутое типа COCOMOII GZ>И вообще, в приложении все должно быть таким, чтобы удовлетворяло клиента. И обивка для кресел, и мотор.
Любая морда может быть прикручена. Потом. Но в проектировании мордам не место!
Здравствуйте, Cyberax, Вы писали:
>> Проблемы возникают если про эти разделяемые ресурсы забывают при >> проектировании, думая, что "фигня, потом приковыряем". C>Если бы учли их сразу — то не писали бы в виде агентов.
???
C>А вот фига. Базу и так уже можно считать агентом, который отвечает на C>запросы по некоторому протоколу. Проблема с семантикой работы с данными C>в БД.
Для "интеллектуального" агента БД слишком сложна. Так что нет, нельзя считать. Надо упростить сначала.
C>Проблема в том, что разные клиенты могут видеть разное состояние БД C>в зависимости от своего транзакционного состояния и состояния C>остальных клиентов. А еще в жестоком реальном мире есть триггеры C>в БД, хранимые процедуры и нарушения constraint'ов.
Вот именно.
C>Более того, у БД нет цельного состояния — ее корректно можно C>моделировать в агентской парадигме только если считать каждую строку C>отдельным агентом.
Вообще-то однозначности состояния от агента не требуется...
C>Алгоритмы становятся распределенными, если между ними есть разделяемое C>состояние (база данных).
Так для этого и надо вносить уровень, изолирующий это состояние от всех прочих.
Здравствуйте, VladD2, Вы писали:
K>> И что же тут не так? Наблюдение моё совершенно объективное. Сторонники genuine windows way любой разговор про КОП сводят к документам и оффисам. Что характерно, сторонники unix way об этом классе задач обычно вообще не думают, он им не интересен. Гораздо более крупными системами занимаются, вестимо.
VD>А чем измеряется крупность системы?
Здравствуйте, Kolhoz, Вы писали:
S>>А скажите пожалуйста, вы считаете что утверждение 2+2=4 всегда и везде верно? И доказать это можете?
K> Когда не указано специально, считается, что применяется аксиоматика целых чисел. Обычно используется аксиоматика Пеано. В её рамках 2+2 всегда будет 4, и это доказывается элементарно. Таковы правила языка — есть набор общепринятых умолчаний. Если же будет сказано, что эта запись — на другом языке, в другой аксиоматике — то это уже будет и совершенно другое утверждение.
тогда чем вы можете объяснить свои категорические заявления, без ознакомления о чем (тобишь о каких условиях) речь идет?
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Kolhoz, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Видите, с какими противоположными взглядами здесь общаются люди. Если мне школьник скажет, что на небе 102346234846 звезд, то для меня это будет совершенно непроверенная информация. Если же это число скажет профессор-астроном, то я с большой вероятности приму это значение на веру.
K> А я на веру ничего принимать не буду. Я попрошу библиографические ссылки, и постараюсь убедиться, что число получено из нескольких независимых источников.
ну дык берем теже "торсионные поля", открываешь гугль и тебе валится миллионы ссылок на "независимые" источники... ты принимаешь эту инфу достоверной?
K>И тогда степень довария к этой информации будет довольно большой. Но естественно не 100%, к фактической информации такого довария не может быть никогда просто по определению. И, кстати, чем более важна для меня информация (то есть — если она используется в моих собственных рассуждениях), тем более низкий первоначальный коэффециент доверия она получит, и тем больше усилий по проверке её мне придётся приложить. Так что да, про количество звёзд я приму с высокой степенью доверия хотя бы от того, что мне абсолютно наплевать, сколько их там видно. Мне эта информация совершенно бесполезна.
ну а какже логические проверки — надож агрегат какойнить построить проверить на практике...
Гдеж хваленая логика и знания жестко выстроенные на основе доказательств?
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Kolhoz, Вы писали:
K> Любая морда может быть прикручена. Потом. Но в проектировании мордам не место!
Не любая. Я принимал участие в разработке трехзвенки так вот там очень много чего проектировалось с оглядкой на морду вернее множество морд. И это не считая того что саму морду тоже очень не мало попроектировать пришлось.
Причем однажды нарисованная форма долюна была отображаться во всех этих мордах... а морды очень разные от Web до Win...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Kolhoz wrote: > C>Если бы учли их сразу — то не писали бы в виде агентов. > ???
Не очень-то и подходит агентская (ака SOA) архитектура для
enterprise-приложений.
> C>А вот фига. Базу и так уже можно считать агентом, который отвечает на > C>запросы по некоторому протоколу. Проблема с семантикой работы с данными > C>в БД. > Для "интеллектуального" агента БД слишком сложна. Так что нет, нельзя > считать. Надо упростить сначала.
А вот как?
> C>Более того, у БД нет *цельного* состояния — ее корректно можно > C>моделировать в агентской парадигме только если считать каждую строку > C>отдельным агентом. > Вообще-то однозначности состояния от агента не требуется...
Просто каждая строчка БД может влиять на каждую (например, при рассчете
агрегатных функций).
> C>Алгоритмы становятся распределенными, если между ними есть разделяемое > C>состояние (база данных). > Так для этого и надо вносить уровень, изолирующий это состояние от всех > прочих.
Пытались смоделировать такое. Получалось либо "БД, вид в профиль" или
жестокие требования по ограничению на сценарии работы с БД.
В общем, мое мнение — агентская архитектура хорошо подходит для
некоторых задач — типа роутинга сообщений или массивно-параллельных
систем, но для многих задач она неприспособлена совсем.
Здравствуйте, Kolhoz, Вы писали: K> Вообще, странные вы люди, вендузятники. Кроме как про "документы" ни про что иное и думать не в состоянии. Ваш мирок ограничен "офисом".
А хоть бы и ограничен. Давай ты, как нестранный юниксоид, предожишь нормальный способ делать компаунд-документы. Декларации о "совершенной ненужности" свойственны людям, которые вообще не ориентированы на потребителя. Если потребителю надо иметь докмент, в котором сведен текст+векторная графика+растровая графика+таблицы+диаграммы, то не надо апеллировать к plain-text RFC. Ну вот надо ему это, и все!
И при этом желательно чтобы это было WYSIWYG. Просто потому, что это не просто документ, а плод очень большого объема размышлений. И у пользователя нет ни времени ни желания исследовать шаманство вроде TeX, чтобы только выяснить, как ему добиться одинаковой высоты текстового заголовка и графического логотипа. В 10000 раз быстрее подвинуть границы мышкой.
Это ваш мирок ограничен нердами, которые вообще себе не представляют, что у людей могут быть и другие потребности, кроме как гонять символы по пайпам или тащиться от того, что кастомизированный фраунгофер жмет на 0.4% быстрее стандартного. Людям надо быстро поправить брошюру и отдать ее в типографию, а потом бежать домой удовлетворять потребности из пирамиды Маслоу. Не надо кичиться своей нердностью. Она вполне хороша на своем месте, среди других нердов.
А мы, простые виндузятники, думаем не про "документы". Мы думаем, что usability — это the must. Мы стараемся дать людям больше времени заниматься некомпьютерными занятиями. Мы считаем, что когда происходит кофликт "человек-машина" (а точнее, в наше время это уже давно "человек-софт") мы считаем, что надо чинить машину, а не учить человека.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, McSeem2, Вы писали: MS> MS>Ну вот какой кретин решил, что при копировании надо портить картинку и приводить ее к стандартным 256 цветам поносного цвета?! И это Это Office 2003!
Нет, это Paint. Просто паинт работает с текущим документом. И если ты не озаботился заранее поставить ему нужную палитру, то упс. Выставь в свойствах изображения 32 бита и все станет немного лучше.
MS>Так каков правильный способ copy-paste? Вот именно — сделать screenshot, после чего с помощью Paint вырезать нужный фрагмент и вставить его как битмап. Собственно на этом так называемые "безграничные возможности" буфера обмена и заканчиваются.
MS>Может я чего-то не понимаю, но меня от подобной халтуры тошнит. Как вся эта помойка может нравиться, я тем более не понимаю. Ребята! Брынза не бывает зеленого цвета — это вас кто-то обманул.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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, или чего там еще.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Streamer1, Вы писали:
S>ну а какже логические проверки — надож агрегат какойнить построить проверить на практике...
-- Старая китайская пословица гласит, -- наконец заговорил он, -- что
тот, кто первый откажется от словесных аргументов и начнет размахивать
руками, признается в интеллектуальной несостоятельности.
-- Разумеется, -- ответил Джо. -- Это не подлежит ни малейшему
сомнению: если для доказательства своей правоты тебе нужен эксперимент,
значит, ты плохой философ и логик.
S>Гдеж хваленая логика и знания жестко выстроенные на основе доказательств?
-- О чем ты болтаешь? Логика третьего уровня? Но ведь ты не...
-- Тебе не понять. Это более сложно, чем "ноумен" Канта, который можно
постичь только мысленно. Чтобы это понять, ты должен уметь когитовать, но...
Что ж, собственно, это и есть третий уровень. Это... сейчас, сейчас...
демонстрация природы вещей, исходя из того, что они происходят не сами по
себе.
-- Эксперимент?
-- Нет, когитация. Я перевожу все вещи из материальной сферы в область
чистой мысли и только тогда делаю логические выводы.
-- Но... минуточку. Ведь кое-что произошло! Я понял, что случилось с
дедушкой и Хардингом, и разработал ускоряющее средство...
-- Это тебе только кажется, -- сказал Джо. -- Я просто когитовал, а это
процесс суперинтеллектуальный. Когда же я закончил, события просто не могли
не произойти. Но, надеюсь, ты не думаешь, будто они происходили сами по
себе?
Здравствуйте, Sinclair, Вы писали:
S>Почему Gmail рулит, а Yahoo! Mail сосет? Првильно, потому что Gmail удобнее.
Не самый удачный пример. Многие пользователи Yahoo! Mail забили на него после того, как POP3 доступ к Yahoo! Mail в 2001 или 2002-м сделали платным. Да и на момент появления Gmail с 1Gb почтовым ящиком, размер ящика на Yahoo! был какой-то совсем маленький (кажется 25Mb). А в 2001 Yahoo! Mail в связке с Yahoo! Chat была просто отличной службой. Так что Yahoo! Mail урыл его же собственный маркетинг.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
S>>Гдеж хваленая логика и знания жестко выстроенные на основе доказательств?
ANS>
ANS>Логика третьего уровня? Но ведь ты не...
ANS>-- Тебе не понять. Это более сложно, чем "ноумен" Канта, который можно
ANS>постичь только мысленно. Чтобы это понять, ты должен уметь когитовать, но...
ANS>Что ж, собственно, это и есть третий уровень. Это... сейчас, сейчас...
ANS>демонстрация природы вещей, исходя из того, что они происходят не сами по
ANS>себе.
ANS>-- Эксперимент?
ANS>-- Нет, когитация. Я перевожу все вещи из материальной сферы в область
ANS>чистой мысли и только тогда делаю логические выводы.
ANS>-- Но... минуточку. Ведь кое-что произошло! Я понял, что случилось с
ANS>дедушкой и Хардингом, и разработал ускоряющее средство...
ANS>-- Это тебе только кажется, -- сказал Джо. -- Я просто когитовал, а это
ANS>процесс суперинтеллектуальный. Когда же я закончил, события просто не могли
ANS>не произойти. Но, надеюсь, ты не думаешь, будто они происходили сами по
ANS>себе?
мдя, если это логикой называется... вобщем не удивительно...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Sinclair, Вы писали:
>И у пользователя нет ни времени ни желания исследовать шаманство вроде TeX, чтобы только выяснить, как ему добиться одинаковой высоты текстового заголовка и графического логотипа. В 10000 раз быстрее подвинуть границы мышкой. S>Это ваш мирок ограничен нердами, которые вообще себе не представляют, что у людей могут быть и другие потребности, кроме как гонять символы по пайпам или тащиться от того, что кастомизированный фраунгофер жмет на 0.4% быстрее стандартного. Людям надо быстро поправить брошюру и отдать ее в типографию, а потом бежать домой удовлетворять потребности из пирамиды Маслоу. Не надо кичиться своей нердностью. Она вполне хороша на своем месте, среди других нердов.
Давно не видел столько ерунды на квадратном метре. С чего вы взяли, что навязанные МС потребности являются таковыми? С чего вы взяли, что набрать команду на клавиатуре займет больше времени, чем надрачивать мышкой, пытаясь сдвинуть тонкую линию. Не говоря уже о том, что эта операция одна из простейших, а стоит зайти немного в лес и без тостенного талмуда по Word уже ни в чем не разберешься. Признайтесь лучше, что дело совсем не в нердности, а в безмерной лени и нежелании научиться хоть чему-то новому. В желании сляпать по быстрому какую-нибудь поделку и побежать удовлетворять потребности в ближайшую пивную.
Здравствуйте, Quintanar, Вы писали:
Q>Давно не видел столько ерунды на квадратном метре. С чего вы взяли, что навязанные МС потребности
И каким же это образом МС навязала кому-то потребности? Для справки: Юникс старше винды в два раза. И как-то не видно множества домохозяек и секретарш, которые поленились осваивать надрачивание мышкой в пользу старого доброго друга. Q>являются таковыми? С чего вы взяли, что набрать команду на клавиатуре займет больше времени, чем надрачивать мышкой, пытаясь сдвинуть тонкую линию. Не говоря уже о том, что эта операция одна из простейших, а стоит зайти немного в лес и без тостенного талмуда по Word уже ни в чем не разберешься. Признайтесь лучше, что дело совсем не в нердности, а в безмерной лени и нежелании научиться хоть чему-то новому.
У кого? У пользователей? Ну так это завсегда так у нердов — им подавай других пользователей. А мы, видишь ли, работаем с теми пользователями, которые есть. Мы их любим и уважаем.
И доля рынка винды на десктопах явно показывает небезответность этой любви. Q>В желании сляпать по быстрому какую-нибудь поделку и побежать удовлетворять потребности в ближайшую пивную.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, eao197, Вы писали:
E>Кстати да, после некоторого опыта работы с LaTeX меняется подход к написанию документов. Особенно, когда используешь собственные команды (либо собственные verbatim, или собственные колонтитулы) и одним легким движением руки изменяешь оформление всех однотипных фрагментов во всем документе -- это впечатляет.
Здравствуйте, Andy Panda, Вы писали:
E>>Кстати да, после некоторого опыта работы с LaTeX меняется подход к написанию документов. Особенно, когда используешь собственные команды (либо собственные verbatim, или собственные колонтитулы) и одним легким движением руки изменяешь оформление всех однотипных фрагментов во всем документе -- это впечатляет.
AP>Казалось бы — причем тут стили в Word'е?
Вот в LaTeX-е я использую следующую команду для помещения в текст ссылки на другой раздел документа:
\newcommand{\fullref}[1]{\ref{#1} на стр.~\pageref{#1}}
Используется, например, так:
Подробнее см.\fulref{sec:SomeChaper:SomeSection}.
И получается:
Подробнее см.4.5 на стр. 28.
Изменив команду fulref и не изменяя текста я могу, например, получать следующий эффект:
Подробнее см.4.5 (стр.28).
Можно ли сделать это стилями Word-а?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote: > И получается: > Подробнее см.4.5 на стр. 28. > Изменив команду fulref и не изменяя текста я могу, например, получать > следующий эффект: > Подробнее см.4.5 (стр.28). > Можно ли сделать это стилями Word-а?
Insert->Reference->Cross-reference. Есть еще какие-то smart-tag'и для этого.
Здравствуйте, kan_izh, Вы писали:
>> Уж не заслуга ли Линукс в том, что эти технологии работают и на нем тоже? _>Некоторые вещи пишут под линух, под винду портят. Тот же mysql/apache, объявляя, что "оно как-то работает", как никто не _>гарантирует...
Однако работают и очень неплохо.
Тоже самое можно в общем-то сказать и виндовс-продуктах. Некоторые вещи пишут под виндовс, под линукс портируют/переписывают. Например, Mono/Rotor.
А некоторые вообще есть только под виндовс, например, MS SQL.
Только какое это отношение имеет к делу?
Я еще раз повторяю свой вопрос, что перечисленные технологии не не работают под Виндовс? Или заслуга Линукс в том, что они запускаются не нам?
ибочны.
_>Я неудачник, убью себя на досуге.
Можно просто перестать выливать кучу фобий и лозунгов на людей.
Я еще понимаю когда кто-то что-то переоценивает или еще что, но когда вот так вот откровенная неправда выливается тоннами — это уже понять трудно.
>> _> Винда — набор "всё в одном". Ставишь винду — получаешь сразу всё, >> хотя не всегда лучшего качества и не всегда адекватного. Линух — >> конструктор "собери сам", собираешь по своему вкусу, требованиям, железу. >> Высосанное из пальца утверждение. Если конечно не брать в рассчет, что >> можно заняться самостятельным потчиньем ядра. _>Собственно, почему не брать?
Птотому что нужно быть не совсем в себе, чтобы начать вместо своей работы заниматься компиляцией ядер ОС.
_>Не укладывается в твою супер-концепцию? Кстати, неплохо бы вспомнить, что винда по этому _>пути "гибкости" пошла по необходимости, чтобы противостоять конкуренции. Гибкость линуксов же — by design, с рождения.
По какому пути Виндва пошла? Ты вообще историю то хорошо знаешь?
>> Я имею под Виндовс все то что под Линукс и немного больше. Обратное не >> верно. А раз так, то все что можно сказать об линуксе можно сказать и о >> Виндовс. _>Что "немного больше" (особенно с т.з. сабжа)?
Так мелочь. Все продукты МС и продукты сделанные только под виндовс. Например 90% игрушек и систем атоматизации бизнеса доступны только под Виндовс. Попробуй найти ФарКрай или 1Эс под Линукс.
>> _>В винду встроено COM+, и отключить его просто так не получится, тебе >> оно навязано. >> Начнем с того, что есть встраиваемыме версии Виндовс в которых ни КОМ-а, >> ни даже графической оболочки нет. Так что это твое незнание проблемы >> говорит. Виндовс на КОМ не основана. Он в ней часто применяется как >> средство абстракции и компонентизации, но и только. _>Если так рассуждать, то в чём тогда сабж?
См. выделненное жирным.
>> Ну, и главное. Что собственного плохого в наличии КОМ? Вот его отсуствие >> является для многих минусом. _>Вообще говоря, по отношению к сабжу, то, что его считают "правильным" для винды.
Хм. Свежая мысль однако.
Кто считает? Я вот знаю КОМ очень неплохо, но так не считаю. Мне вот компонентная модель Явы и дотнета нравится куда больше. Хотя как средство межязыковой интеграции КОМ пока что никем не превзойден. Назови хотя бы одну компонентную технологию которая поддерживалась бы в стольких языках.
>> _> А некоторые дистрибы линуха вполне >> _>могут содержать какую-нидь КОП платформу, на которой дистриб построен >> (та хрень в KDE, например), но это не входит как >> _>неотъемлемая часть в линух вообще. >> И что? Какое это отношение имеет к делу и к откоровенно неверным и мягко >> говоря лукавым заявлениям сделанным тобой выше? _>Попробуй порассуждать: _>"КОП в винде" — такого вопроса нет. Сразу очевидно = COM, .NET. _>"КОП в линух" — вопрос? Да что угодно!
Опять ответа на вопрос нет. Разговаривать с фанатиками желания нет. Всего хорошего.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> Зашибись. Значит под виндовс "java, mono, corba, XPCOM, SOAP, всё что >> угодно" не приминимы? Если "да", то откровенно говоря закрыдываются >> сомнения на счет твоего знания Виндовс. C>Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM.
В чем смысл этого ответа?
>> Если "нет" (т.е. применимы), >> тогда закрадывается сомнение в честности высказывания. C>Вероятно, имелось в виду, что определенная реализация КОП уже намертво C>защита в Винду.
Серьезно? И что помешает мне на "винде" испльзовать XPCOM или Java?
Да и не кажется ли странным такой перевод его слов? Мне кажется все проще. Еще один фанатик который не хочет признавать очевиднейших вещей и который верит в свои заблуждения. Вот и разговаривать с ним нельзя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Нет, это Paint. Просто паинт работает с текущим документом. И если ты не озаботился заранее поставить ему нужную палитру, то упс. Выставь в свойствах изображения 32 бита и все станет немного лучше.
Не совсем. Там в буфере обмена присутствуют:
Microsoft Word Object
Enhanced Metafile
Bitmap
HTML
Paint берет Bitmap и он 256-цветный. IrfanView делает то же самое. Exel по умолчанию берет что-то другое и растягивает изображение на 1 пиксел, за что вообще надо бить канделябром. Copy-Special/Bitmap дает правильные размеры, но 256 цветов. Нормально через буфер обмена передается только unformatted plain text.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
VD>Так мелочь. Все продукты МС и продукты сделанные только под виндовс. Например 90% игрушек и систем атоматизации бизнеса доступны только под Виндовс. Попробуй найти ФарКрай или 1Эс под Линукс.
Сейчас уже все идет к тому что 90% игрушек будут недоступны под windows, а если ms затянет с вистой это очень быстро может стать реальностью.
K> Обе эти убогонькие программульки никакого отношения к unix way не имеют. А вот R + MySQL + Python + latex + gnuplot + maxima идеально вяжутся в одну систему, и, как показывает практика, вендовозные ламеры, любители поредактировать табличку в текстовом процессоре, по эффективности работы просто рядом не валялись с теми кто пользуется подобной связкой. Пара дней — и идеального полиграфического качества статья готова, с идеальными графиками и достоверно проверенным качеством вывода и рассчётов. Вордописцы будут с тем же самым возиться не меньше месяца, как, опять же, демонстрирует та же самая практика.
MySQL + Python... и "Пара дней — и идеального полиграфического качества статья готова".
Ты вообще с полиграфий то имел дело?
Ты меня "виндовозного ламера" извини, но если мы будем тратить по паре дней на верстку одной статьи, то вылетим в трубу.
У нас за пару дней журнал верстается, цветной.
ЗЫ
Давно я такого фантатизма не видел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>А Reiser4FS на Винде есть? Или любая другая нормальная FS, которая не > C>торомзит? > А меня и NTFS устравивает. Зачем мне искать от добра дотбра?
А вот меня не устраивает. Так как NTFS — клинический тормоззззззз (я уже
приводил здесь тесты, в которых Reiser4 был в разы быстрее).
VD>>Так мелочь. Все продукты МС и продукты сделанные только под виндовс. Например 90% игрушек и систем атоматизации бизнеса доступны только под Виндовс. Попробуй найти ФарКрай или 1Эс под Линукс.
FR>Сейчас уже все идет к тому что 90% игрушек будут недоступны под windows, а если ms затянет с вистой это очень быстро может стать реальностью.
МС может легко затянуть с Вистой еще на 2 года, и никто этого не заметит. Народ только-только с 98-й (!) на более поздние версии переползает. WinXP покрывает текущие потребности пользовательского рынка винд на 100%. Win2k + WinServer 2003 — потребности виндового серверного рынка. А производителям игрушек даже с выходом Висты еще года полтора-два может быть до Висты фиолетово.
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
VD>MySQL + Python... и "Пара дней — и идеального полиграфического качества статья готова". VD>Ты вообще с полиграфий то имел дело?
VD>Ты меня "виндовозного ламера" извини, но если мы будем тратить по паре дней на верстку одной статьи, то вылетим в трубу. VD>У нас за пару дней журнал верстается, цветной.
Не, ну если этот весь процесс автоматизировать... Пишется shell-script, который вызывает связку R + MySQL + Python + latex + gnuplot + maxima ... Но это еще надо суметь автоматизировать...
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Mamut, Вы писали:
FR>>Сейчас уже все идет к тому что 90% игрушек будут недоступны под windows, а если ms затянет с вистой это очень быстро может стать реальностью.
M>МС может легко затянуть с Вистой еще на 2 года, и никто этого не заметит. Народ только-только с 98-й (!) на более поздние версии переползает. WinXP покрывает текущие потребности пользовательского рынка винд на 100%. Win2k + WinServer 2003 — потребности виндового серверного рынка. А производителям игрушек даже с выходом Висты еще года полтора-два может быть до Висты фиолетово.
Производители игрушек сейчас массово бегут с PC на игровые приставки, уже больше 50 процентов игр или вообще не выходит на PC или выходит с запозданием. Ms обещала что виста будет полноценной игровой системой с подержкой всех сервисов от Xbox.
Здравствуйте, Mamut, Вы писали: M>Не, ну если этот весь процесс автоматизировать... Пишется shell-script, который вызывает связку R + MySQL + Python + latex + gnuplot + maxima ... Но это еще надо суметь автоматизировать...
Самое трудное — это автоматизировать процесс написания статьи.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Mamut, Вы писали:
FR>>>Сейчас уже все идет к тому что 90% игрушек будут недоступны под windows, а если ms затянет с вистой это очень быстро может стать реальностью.
M>>МС может легко затянуть с Вистой еще на 2 года, и никто этого не заметит. Народ только-только с 98-й (!) на более поздние версии переползает. WinXP покрывает текущие потребности пользовательского рынка винд на 100%. Win2k + WinServer 2003 — потребности виндового серверного рынка. А производителям игрушек даже с выходом Висты еще года полтора-два может быть до Висты фиолетово.
FR>Производители игрушек сейчас массово бегут с PC на игровые приставки, уже больше 50 процентов игр или вообще не выходит на PC или выходит с запозданием. Ms обещала что виста будет полноценной игровой системой с подержкой всех сервисов от Xbox.
Ну так это давно известно. ИМХО рынок игровых приставок уже переплюнул рынок игр для PC и игроки на PC зачастую получают ошметки с обеденного стола.
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
VladD2 wrote:
> Птотому что нужно быть не совсем в себе, чтобы начать вместо своей > работы заниматься компиляцией ядер ОС.
Хм. Те кто работает со спец.железками не совсем в себе?
> _>Не укладывается в твою супер-концепцию? Кстати, неплохо бы вспомнить, > что винда по этому > _>пути "гибкости" пошла по необходимости, чтобы противостоять > конкуренции. Гибкость линуксов же — by design, с рождения. > По какому пути Виндва пошла? Ты вообще историю то хорошо знаешь?
Фактически по x86, а всякие alpha были так... А уж если сравнивать ситуацию несколько лет назад... попробуй винду
поставить и юзать на железку без монитора/клавы/и не дай бог мыши. Только недавно задумались о командной строке в винде.
Терминальный сервер более менее стал позволять работать без ограничений удалённо.
>> > Я имею под Виндовс все то что под Линукс и немного больше. Обратное не >> > верно. А раз так, то все что можно сказать об линуксе можно сказать и о >> > Виндовс. > _>Что "немного больше" (особенно с т.з. сабжа)? > Так мелочь. Все продукты МС и продукты сделанные только под виндовс. > Например 90% игрушек и систем атоматизации бизнеса доступны только под > Виндовс. Попробуй найти ФарКрай или 1Эс под Линукс.
1с вполне как-то живёт под wine, там были проблемы (вроде 1с что-то решила по этому поводу) в основном с лиценз.
защитой, основанной на железе (hasp или как там его).
До игрушек мне пофиг, а посему вообще ничего об этом не знаю. Кто такой фаркрай?..
>> > _>*В винду встроено COM+*, и отключить его просто так не получится, тебе >> > оно навязано. >> > Начнем с того, что есть встраиваемыме версии Виндовс в которых ни КОМ-а, >> > ни даже графической оболочки нет. Так что это твое незнание проблемы >> > говорит. Виндовс на КОМ не основана. Он в ней часто применяется как >> > средство абстракции и компонентизации, но и только. > _>Если так рассуждать, то в чём тогда сабж? > См. выделненное жирным.
Да, согласен, несколько слукавил, выкинуть можно. Я больше имел в виду, что линух в этом отношении честнее — ни com ни
.net и ничего подобного нет "по умолчанию", ничего не навязывается.
> _>Вообще говоря, по отношению к сабжу, то, что его считают "правильным" > для винды. > Хм. Свежая мысль однако. > Кто считает? Я вот знаю КОМ очень неплохо, но так не считаю. Мне вот > компонентная модель Явы и дотнета нравится куда больше. Хотя как > средство межязыковой интеграции КОМ пока что никем не превзойден. Назови > хотя бы одну компонентную технологию которая поддерживалась бы в > стольких языках.
Pure C (dll/so)?
А что, модель компиляции исходников в линухе и иже с ними — вполне таки компонентная модель. Простая как швабра, дуб
дубом (в смысле крепкая).
> _>Попробуй порассуждать: > _>"КОП в винде" — такого вопроса нет. Сразу очевидно = COM, .NET. > _>"КОП в линух" — вопрос? Да что угодно! > Опять ответа на вопрос нет. Разговаривать с фанатиками желания нет.
Ну если тебе хочется просто поболтать, то не ко мне. Хочется подумать, то задумайся о сабже.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
FR>>Производители игрушек сейчас массово бегут с PC на игровые приставки, уже больше 50 процентов игр или вообще не выходит на PC или выходит с запозданием. Ms обещала что виста будет полноценной игровой системой с подержкой всех сервисов от Xbox.
M>Ну так это давно известно. ИМХО рынок игровых приставок уже переплюнул рынок игр для PC и игроки на PC зачастую получают ошметки с обеденного стола.
Так тут же сказали
Например 90% игрушек и систем атоматизации бизнеса доступны только под Виндовс
VladD2 wrote: > C>Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM. > В чем смысл этого ответа?
Чтобы сомнений в компетентности не возникало.
> C>Вероятно, имелось в виду, что определенная реализация КОП уже намертво > C>защита в Винду. > Серьезно? И что помешает мне на "винде" испльзовать XPCOM или Java?
Ничто. Ничего, кроме того, что ни одна распространенная тулза разработки
для Windows на него не ориентирована.
> Да и не кажется ли странным такой перевод его слов? Мне кажется все > проще. Еще один фанатик который не хочет признавать очевиднейших вещей и > который верит в свои заблуждения. Вот и разговаривать с ним нельзя.
M>>Ну так это давно известно. ИМХО рынок игровых приставок уже переплюнул рынок игр для PC и игроки на PC зачастую получают ошметки с обеденного стола.
FR>Так тут же сказали FR>
FR>Например 90% игрушек и систем атоматизации бизнеса доступны только под Виндовс
Ну, будем иметь в виду игрушки для PC
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
M>Не, ну если этот весь процесс автоматизировать... Пишется shell-script, который вызывает связку R + MySQL + Python + latex + gnuplot + maxima ... Но это еще надо суметь автоматизировать...
И что в статью можно из MySQL вынуть? Да и верстка процесс творческий полностью не автоматизирвется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kan_izh, Вы писали:
_>Хм. Те кто работает со спец.железками не совсем в себе?
Та же виндовс разбирается на части без перекомпиляции. Даже есть специальный соят для формирования специализированных встраеваемых версий. Так что если в Линуксе это не делается, то это его личные проблемы, а не идеологические.
>> _>Не укладывается в твою супер-концепцию? Кстати, неплохо бы вспомнить, >> что винда по этому >> _>пути "гибкости" пошла по необходимости, чтобы противостоять >> конкуренции. Гибкость линуксов же — by design, с рождения. >> По какому пути Виндва пошла? Ты вообще историю то хорошо знаешь? _>Фактически по x86, а всякие alpha были так... А уж если сравнивать ситуацию несколько лет назад...
К сведению, к Виндовс отосятся кроме ХРюши еще Мобаил- и ЦЕ-версии которые работают на куче разнообразных железок.
Но это к делу не относится. Я говорил об истории. Дело в том, что архитектура NT была сформирована еще до того как появились первые сообщения о Линуксе. И формиловалась она под влиянием очень известного человека в мире миникомпьютеров. NT изначально была архитектурно более гибка чем Линукс. А линукс как раз послал к чертям все завоевания научной мысли тех лет и породил монолитную архитектуру смело шагнувшую на много лет назад.
_> попробуй винду _>поставить и юзать на железку без монитора/клавы/и не дай бог мыши. Только недавно задумались о командной строке в винде.
Ага. Только недавно. Примерно в 1992-ом году. А в 2000-ном был вариант виндовс для встаеваемых систем вообще не имеющих GUI и управляемый исключительно из командной строки удаленно.
_>Терминальный сервер более менее стал позволять работать без ограничений удалённо.
В общем, приплыли. Сервер на котором ты сейчас общашся работает под управлением Windows 2003 Server. У него нет ни клавиатуры, ни монитора, ни мыши и вообще к нему по два года никто физически не подходит. Управляется он через терминал-сервис причем многие лезут на сервер с другой стороны земного шара.
Терминалка у нас работает с момента появления этого сайта в 2002 году.
_>Да, согласен, несколько слукавил, выкинуть можно. Я больше имел в виду, что линух в этом отношении честнее — ни com ни _>.net и ничего подобного нет "по умолчанию", ничего не навязывается.
Нет тут никакой честности. Правда в том, что в Линукс просто нет никаких компонентных технологий бай дефолт. Зато есть возможность пользоваться общеупотребимыми. Что в общем-то не хуже и не лучше чем в других ОС. И нечего тут разводить политические дрязги.
>> _>Вообще говоря, по отношению к сабжу, то, что его считают "правильным" >> для винды. >> Хм. Свежая мысль однако. >> Кто считает? Я вот знаю КОМ очень неплохо, но так не считаю. Мне вот >> компонентная модель Явы и дотнета нравится куда больше. Хотя как >> средство межязыковой интеграции КОМ пока что никем не превзойден. Назови >> хотя бы одну компонентную технологию которая поддерживалась бы в >> стольких языках. _>Pure C (dll/so)?
Это вообще не компонентные технологии.
_>А что, модель компиляции исходников в линухе и иже с ними — вполне таки компонентная модель. Простая как швабра, дуб _>дубом (в смысле крепкая).
У тебя очень странные понятия о компонентых технологиях. Компоненты обязаны позволять стрить программу из поставляемых одтедьно модулей. При этом не должна требоваться компиляция или информация о модулях в текстовом виде.
Кроме того компонетная технология подразумевает наличие инфраструктуры. Ведь просто загрузка модулей мало интересна. Важно наличие фрэймворка позволяющего эффективно разработывать софт с его помощь. Ведь в принципе КОМ без проблем можно реализовать с нуля на С++. Вот только это огромный объем работы время на который изымается из времени отведенного на основные проекты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> C>Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM. >> В чем смысл этого ответа? C>Чтобы сомнений в компетентности не возникало.
Ты мои сообщения, то в этой ветке читал?
Я где-то говорил, что в Линукс недоступны компонетные технологии?
Создается впечателине, что тебе пофигу что на что отвечать. Лишбы возразить.
>> C>Вероятно, имелось в виду, что определенная реализация КОП уже намертво >> C>защита в Винду. >> Серьезно? И что помешает мне на "винде" испльзовать XPCOM или Java? C>Ничто. Ничего, кроме того, что ни одна распространенная тулза разработки C>для Windows на него не ориентирована.
Это лож. Сред разработки для Явы под виндовс больше всего насвете.
XPCOM просто самопальный клон КОМ-а который можно использовать в любом компиляторе С++ при наличии соотвествующих библиотек.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>А вот меня не устраивает. Так как NTFS — клинический тормоззззззз (я уже > Извини, но это руки.
Спорим?
> C>приводил здесь тесты, в которых Reiser4 был в разы быстрее). > Туфта там били а не тесты. Левая синтетика.
Правая синтетика — инкрементальная перестройка проекта BJam'ом на
Линуксе работает в десять (десять!) раз быстрее. Как показал профилятор
— большая часть времени в Винде тратится на stat()'инг файлов.
> C>И вот фиг ты ее заменишь на нормальную FS. > В NT файловые системы так же сменяемые. Только вот есть одна прямая > реализация и не у гого нет желания заниматься велосипидизмом.
Да? Вот покажи мне как в этих замечательных сменяемых FS добавить
поддержку безопасности и возможность загрузки с них.
ЗЫ: в Винде поставлены настройки большого кэша, отключены 8.3-имена и
поддержка времени последнего доступа к файлам.
VladD2 wrote: > _>Хм. Те кто работает со спец.железками не совсем в себе? > Та же виндовс разбирается на части без перекомпиляции. Даже есть > специальный соят для формирования специализированных встраеваемых > версий. Так что если в Линуксе это не делается, то это его личные > проблемы, а не идеологические.
Это просто ты со встраиваемыми устройствами не работал. В дистрибутиве
WinCE просто содержаться объектные файлы, скомпилированные для всех
поддерживаемых архитектур. Из них собирается готовый образ с нужной
функциональностью.
Точно так же можно делать и в Линуксе — но зачем заниматься сексом, если
есть исходники и проще их скомпилировать под целевую платформу?
Кстати, и отладка на уровне исходников тогда возможна.
Причем для этого MS пришлось полностью переписать все — у WinCE
полностью свое ядро, не имеющее ничего общего с NT.
> К сведению, к Виндовс отосятся кроме ХРюши еще Мобаил- и ЦЕ-версии > которые работают на куче разнообразных железок.
И которые не имеют ничего общего с NT.
> И формиловалась она под влиянием очень известного > человека в мире миникомпьютеров. NT изначально была архитектурно более > гибка чем Линукс. А линукс как раз послал к чертям все завоевания > научной мысли тех лет и породил монолитную архитектуру смело шагнувшую > на много лет назад.
Ага, но при этом сейчас Линукс является самым быстрым ядром для
десктопных ОС. А NT так и не стала микроядерной.
В OS X используют медленный Mach, а NT имеет "псевдомикроядерную"
архитектуру — часть Win32API работает в отдельном сервере. Но если этот
сервер падает — то падает и вся система (в Win2K при этом выдается
красивое окошко с обратным отсчетом).
M>>Не, ну если этот весь процесс автоматизировать... Пишется shell-script, который вызывает связку R + MySQL + Python + latex + gnuplot + maxima ... Но это еще надо суметь автоматизировать...
VD>И что в статью можно из MySQL вынуть?
Почему бы и нет
Какой-нить связкой bash + vim + gettext + MySQL
VD>Да и верстка процесс творческий полностью не автоматизирвется.
Это увы..
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Cyberax, Вы писали:
>> Извини, но это руки. C>Спорим?
C>Правая синтетика — инкрементальная перестройка проекта BJam'ом на C>Линуксе работает в десять (десять!) раз быстрее. Как показал профилятор C>- большая часть времени в Винде тратится на stat()'инг файлов.
Я не знаю что такое BJam и не знаю что такое stat(). Но я периодически обрабатываю большие объемы информции и знаю, что при грамотном подходе проблем в дисковой подсистеме нет.
C>Да? Вот покажи мне как в этих замечательных сменяемых FS добавить C>поддержку безопасности и возможность загрузки с них.
Загрузка происходит с МБР, а что до безопасности то тебе вроде скорость нужна была. В общем, тебе явно нужна пенисометрия не имеющая ничего общего с жизнью. А по жизни НТФС всем хватат за глаза. Потому никого твоя пенисометрия не колшит. В Линуксе 99.9% тоже ставя то что идет по умолчанию и не выпендриваются.
И вообще зря я стобой снова спорить влез. Речь шала о доступных под ОС возможностях. Сменяемые файловые системы это баловство для очень посвященных. А вот наличие МС Сиквела, Фаркрая, Винкомандера, Студии с дотнетом... она совсем не заменяет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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. Больше никому ничего не
надо.
VladD2 wrote: >> > C>Можешь мне поверить, товарищ kan лично использовал XPCOM, Java и COM. >> > В чем смысл этого ответа? > C>Чтобы сомнений в компетентности не возникало. > Ты мои сообщения, то в этой ветке читал?
Нет, только пишу.
> C>Ничто. Ничего, кроме того, что ни одна распространенная тулза разработки > C>для Windows на него не ориентирована. > Это лож. Сред разработки для Явы под виндовс больше всего насвете.
Среды разработки для Java пишутся (обычно) на Java и работают из-за
этого везде.
> XPCOM просто самопальный клон КОМ-а который можно использовать в любом > компиляторе С++ при наличии соотвествующих библиотек.
А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу
ATLевских, всякие аналоги ATL/MFC Trace Tool?
Здравствуйте, Cyberax, Вы писали:
C>iZEN wrote: >> C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию >> C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем >> C>случае в юниксах эта задача не решается). >> Читайте про VFS (виртуальная файловая система) и про интерфейс >> vnone/vfs, который чётко специфицирует организацию и функционирование >> любой произвольной файловой системы в UNIX. C>Еще раз. Вопрос был как мне добавить СВОЮ реализацию файла. И причем не C>как драйвер в ядро.
FUSE (Filesystem in USErspace) работает на Linux, начиная с версии ядра 2.6.14-rc1, и во FreeBSD. Драйверы FUSE выполняются в пользовательском режиме и могут быть реализованы на языках программирования: C, C++, Java, Haskell, TCL, Python, Perl, Sh, Ocaml, Pliant, Ruby, C#.
На сегодня существует несколько десятков (больше 50) пользовательских файловых систем, реализованных на базе FUSE. Основные функции, такие:
шифрование и сжатие файлов "на лету";
SMB (монтирование при первом обращении, кэширование);
FTP, SSh, WebDAV, Gmail и т.д.;
монтирование содержимого архивов (rar, zip, tar, bzip2, gzip и др.);
монтирование специфических устройств (iPod, мобильные телефоны Siemens, Apple iPhoto DPAP и др.);
монтирование NTFS в режиме read&write (полноценная запись в отличие от той, что содежится в ядре по умолчанию);
хранение файлов в реляционной СУБД.
(по материалам печатного журнала "Системный администратор" №6 (июнь) 2006 года)
Так что, вопрос о компонентности файловой системы на *NIX может быть закрыт? Или есть ещё какие соображения?
Здравствуйте, 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)
Тогда ещё 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>Кроме того компонетная технология подразумевает наличие инфраструктуры. Ведь просто загрузка модулей мало интересна. Важно наличие фрэймворка позволяющего эффективно разработывать софт с его помощь. Ведь в принципе КОМ без проблем можно реализовать с нуля на С++. Вот только это огромный объем работы время на который изымается из времени отведенного на основные проекты.
Здравствуйте, Cyberax, Вы писали:
C>В OS X используют медленный Mach,
Mach НЕ медленный. Это ядро — красивое исключение из правила "все микроядра медленны".
C>а NT имеет "псевдомикроядерную" C>архитектуру — часть Win32API работает в отдельном сервере. Но если этот C>сервер падает — то падает и вся система (в Win2K при этом выдается C>красивое окошко с обратным отсчетом).
Было уже. Каунтдовн у MS вышел на славу: сохранись за одну минуту!
Здравствуйте, Cyberax, Вы писали:
C>Нет, только пишу.
Вот то-то и оно.
C>Среды разработки для Java пишутся (обычно) на Java и работают из-за C>этого везде.
И тем неменее есть работающие только на Виндовс. Причем на виндовс работают все доступные среды. И оно логично.
>> XPCOM просто самопальный клон КОМ-а который можно использовать в любом >> компиляторе С++ при наличии соотвествующих библиотек. C>А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу C>ATLевских, всякие аналоги ATL/MFC Trace Tool?
А что с Цигвином оно не работает?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
iZEN wrote: > C>В OS X используют медленный Mach, > Mach НЕ медленный. Это ядро — красивое исключение из правила "все > микроядра медленны".
Медленный, причем очень сильно. Это очень хорошо заметно на
многопоточных или серверных приложениях.
Кроме того, Mach устроен примерно так же как и NT — там есть один
большой Unix-сервер, внутри которого работают FS, драйвера и Unix-runtime.
iZEN wrote: > C>Еще раз. Вопрос был как мне добавить СВОЮ реализацию файла. И причем не > C>как драйвер в ядро. > FUSE (Filesystem in USErspace) работает на Linux, начиная с версии ядра > 2.6.14-rc1, и во FreeBSD.
FUSE — это сравнительно недавнее появление, да еще и специфичное для
нескольких ОС. Классическая Unix-модель не предлагает никаких средств
расширения FS кроме именованых пайпов/сокетов.
> Так что, вопрос о компонентности файловой системы на *NIX может быть > закрыт? Или есть ещё какие соображения?
Есть, см. выше.
VladD2 wrote: > C>Среды разработки для Java пишутся (обычно) на Java и работают из-за > C>этого везде. > И тем неменее есть работающие только на Виндовс. Причем на виндовс > работают все доступные среды. И оно логично.
Можно пример таких сред? Я знаю, пожалуй, только OmniCore.
>> > XPCOM просто самопальный клон КОМ-а который можно использовать в любом >> > компиляторе С++ при наличии соотвествующих библиотек. > C>А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу > C>ATLевских, всякие аналоги ATL/MFC Trace Tool? > А что с Цигвином оно не работает?
XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что
кроме тулзов из Mozilla для XPCOM больше ничего почти и нет.
Здравствуйте, Cyberax, Вы писали:
C>iZEN wrote: >> C>Еще раз. Вопрос был как мне добавить СВОЮ реализацию файла. И причем не >> C>как драйвер в ядро. >> FUSE (Filesystem in USErspace) работает на Linux, начиная с версии ядра >> 2.6.14-rc1, и во FreeBSD. C>FUSE — это сравнительно недавнее появление, да еще и специфичное для C>нескольких ОС. Классическая Unix-модель не предлагает никаких средств C>расширения FS кроме именованых пайпов/сокетов.
Кто вам такое сказал?
vnode/vfs в UNIX давно придумали?
Вот структурная схема FUSE:
Здравствуйте, Cyberax, Вы писали:
C>Можно пример таких сред? Я знаю, пожалуй, только OmniCore.
VS, например.
>> C>А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу >> C>ATLевских, всякие аналоги ATL/MFC Trace Tool? >> А что с Цигвином оно не работает? C>XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что C>кроме тулзов из Mozilla для XPCOM больше ничего почти и нет.
Это к чему сказано?
У меня орпределенно создается впечатление, что что ты разговариваешь не со мной, а с некими потусторонними силами. Если так будет продолжаться дальше, я буду вынужден просто игнорировать все твои сообщения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Как раз с большими файлами проблем у NTFS нет. Проблемы начинаются с C>кучей мелких файлов.
200-300 тыс. файлов с средним объемом 1 MB — это куча мелких файлов? Реальный пример в моей практике — голосовая почта. В 1MB вмещается около 1 минуты сообщения (PCM, 8KHz, 16 bit, mono). Если нет, то вопрос снят, если да, то задержки на поиск файла и его трансфер через плату IP телефонии можно считать равными нулю.
P.S. возможно, что ФС под никсы могут делать каждое обращение на 1-5 миллисекунды быстрее. А зачем, если с подобными задачами более чем справляется 600-й пень и 128 метров оперативки, который уже вряд-ли купишь в магазине?
VladD2 wrote: > C>Можно пример таких сред? Я знаю, пожалуй, только OmniCore. > VS, например.
А разве в ней есть поддержка Java? Я видел только J#.
> C>XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что > C>кроме тулзов из Mozilla для XPCOM больше ничего почти и нет. > Это к чему сказано? > У меня орпределенно создается впечатление, что что ты разговариваешь не > со мной, а с некими потусторонними силами. Если так будет продолжаться > дальше, я буду вынужден просто игнорировать все твои сообщения.
Тебе вроде бы сказали, что формально в Винде можно использовать другие
компонентные архитектуры. Но реально используется практически только
один COM.
Anton Batenev wrote: > 200-300 тыс. файлов с средним объемом 1 MB — это куча мелких файлов? > Реальный пример в моей практике — голосовая почта. В 1MB вмещается около > 1 минуты сообщения (PCM, 8KHz, 16 bit, mono). Если нет, то вопрос снят, > если да, то задержки на поиск файла и его трансфер через плату IP > телефонии можно считать равными нулю.
Не тот пример. На единичных обращениях это неважно.
> P.S. возможно, что ФС под никсы могут делать каждое обращение на 1-5 > миллисекунды быстрее.
Вот именно это и важно. У меня при компиляции происходит обращение
примерно к 10000 файлов. Сэкономленная миллисекунда на каждом обращении
— это 10 секунд в сумме.
А так как инкрементальную компиляцию я запускаю раз 100 в день — то
общая сумма сэкономленного времени получается очень неплохой.
> А зачем, если с подобными задачами более чем справляется 600-й пень и > 128 метров оперативки, который уже вряд-ли купишь в магазине
А может-таки есть другие задачи?
iZEN wrote: > C>FUSE — это сравнительно недавнее появление, да еще и специфичное для > C>нескольких ОС. Классическая Unix-модель не предлагает никаких средств > C>расширения FS кроме именованых пайпов/сокетов. > Кто вам такое сказал? > vnode/vfs в UNIX давно придумали?
Вопрос на засыпку: я могу из под обычного пользователя в юниксах
добавить в ядро свой модуль и подмонтировать свою FS?
Здравствуйте, Cyberax, Вы писали:
C>iZEN wrote: >> C>FUSE — это сравнительно недавнее появление, да еще и специфичное для >> C>нескольких ОС. Классическая Unix-модель не предлагает никаких средств >> C>расширения FS кроме именованых пайпов/сокетов. >> Кто вам такое сказал? >> vnode/vfs в UNIX давно придумали? C>Вопрос на засыпку: я могу из под обычного пользователя в юниксах C>добавить в ядро свой модуль и подмонтировать свою FS?
Да. Только ядро будет работать с твоим модулем через FUSE (см .схему работы в предыдущем посте).
Если нужно исключить FUSE вообще, то придётся работать через sudo (аналог run as в Windows) для выполнения административных задач по подключению модуля к ядру.
Хотя на разных этапах загрузки можно что угодно сделать в UNIX. Например, во FreeBSD можно вручную на лету подгружать новые ядра и модули на этапе начальной загрузки системы. В Solaris собственный механизм управления загрузкой (там вообще машина может не выключаться). root, как администратор, может дать специальные привелегии пользователям и ещё больше: быть root'ами в собственных операционных окружениях (например, клетка Jail во FreeBSD).
iZEN wrote: > C>Вопрос на засыпку: я могу из под обычного пользователя в юниксах > C>добавить в ядро свой модуль и подмонтировать свою FS? > Да. Только ядро будет работать с твоим модулем через FUSE (см .схему > работы в предыдущем посте).
Я это прекрасно понимаю. Все дело в том, что FUSE — это совсем недавняя
и непортабельная вещь.
> Если нужно исключить FUSE вообще, то придётся работать через sudo > (аналог run as в Windows) для выполнения административных задач по > подключению модуля к ядру.
Несекьюрно и совсем не в духе Unix. Проблема в том, что файл в юниксах —
это абстракция, но системная абстракция, а не пользовательского
уровня.
И если я хочу написать портируемую программу — то могу рассчитывать
только на пайпы/сокеты и временные файлы.
Здравствуйте, Cyberax, Вы писали:
C>iZEN wrote: >> C>Вопрос на засыпку: я могу из под обычного пользователя в юниксах >> C>добавить в ядро свой модуль и подмонтировать свою FS? >> Да. Только ядро будет работать с твоим модулем через FUSE (см .схему >> работы в предыдущем посте). C>Я это прекрасно понимаю. Все дело в том, что FUSE — это совсем недавняя C>и непортабельная вещь.
>> Если нужно исключить FUSE вообще, то придётся работать через sudo >> (аналог run as в Windows) для выполнения административных задач по >> подключению модуля к ядру. C>Несекьюрно и совсем не в духе Unix. Проблема в том, что файл в юниксах — C>это абстракция, но системная абстракция, а не пользовательского C>уровня. FUSE (Filesystem in USErspace) была частью проекта AFVS. Сейчас код выделен в отдельный проект и входит в ядро Linux (старое 2.4 и новое 2.6) и включён в порты FreeBSD 6.x (текущие ветки) and 7.x (экспериментальная ветка).
Представляет собой абстрактный драйвер уровня ядра, который может работать с "драйверами" непривилегированных пользователей (уровня userland). То есть Вы пишете свой "драйвер" и спокойно запускаете его в адресном пространстве пользователя. FUSE с помощью механизма обратных вызовов делает прозрачным работу ядра с вашей собственной файловой системой как с нативной (Ext2fs, Ufs, XFS и т.д.). Это гораздо быстрее, чем с помощью пайпов и тем более сокетов, так как здесь используются вызовы функций, а не пакетные протоколы. C>И если я хочу написать портируемую программу — то могу рассчитывать C>только на пайпы/сокеты и временные файлы. FUSE работает на: http://fuse.sourceforge.net/wiki/index.php/OperatingSystems (Linux и FreeBSD)
Учитывая, что исходный код открыт, можно надеяться, что будет портирован на более экзотические OS.
(Пример из 100 строк на Си для драйвера "Hello World" разве не впечатляет?)
iZEN wrote: > FUSE <http://fuse.sourceforge.net/> (Filesystem in USErspace) была > частью проекта AFVS.
Не надо мне это 10 раз повторять — я прекрасно знаю что такое FUSE.
> C>И если я хочу написать портируемую программу — то могу рассчитывать > C>только на пайпы/сокеты и временные файлы. > FUSE <http://fuse.sourceforge.net/> работает на: > 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
iZEN wrote:
> Выделенное — чистый, незамутнённый бред.
У меня такое же впечатление сложилось... Есть такие люди, которые уверены: Украина — родина слонов.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
C>Вот именно это и важно. У меня при компиляции происходит обращение C>примерно к 10000 файлов. Сэкономленная миллисекунда на каждом обращении C>- это 10 секунд в сумме.
Можно узнать сколько времени занимает процесс компиляции?
C>А так как инкрементальную компиляцию я запускаю раз 100 в день — то C>общая сумма сэкономленного времени получается очень неплохой.
Твои 10 гипотетические секунди если и появляются то, только если речь идет о перекомпиляции всего проекта. А при инкрементальной компиляции их проросту не будет. Так что твоя экономия это секунд 40 растянутые на весь день. Ты реально каждый час прошляпливашь больше.
Потом скорость компиляции куда больше зависит от компилятора. Так MS VS работает куда как быстрее GCC. Стало быть воспользовавшись Виндовс ты свой проект скомпилируешь банально быстрее.
А если выбросись свой С++ то вообще получишь возможность резко ускорить процпсс компляции.
Теперь о том почему твои 10 секунд гипотетические а не реальный.
Только что зашел на свою рабочую машину (ишу с ноута) и провел слерственный экспермент. У меня есть каталог с RSDN Offline (переведенные в html сообщения с форумов РСДН). В каталоге содержится где-то 22.8 тысяч файлов.
Первое нажатие энтера в Винкомандере заставляет машину задуматься где-то на 2-3 секунды. После того как MFT кэшируется открытие каталога занимает менее секунды.
У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не более чем под больного воображения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Вот именно это и важно. У меня при компиляции происходит обращение C>>примерно к 10000 файлов. Сэкономленная миллисекунда на каждом обращении C>>- это 10 секунд в сумме. VD>Можно узнать сколько времени занимает процесс компиляции?
Так же порядка 5-10 секунд. Обычно меняется один-два файла, которые надо перекомпилировать, а пересвязать исполняемый файл.
VD>Твои 10 гипотетические секунди если и появляются то, только если речь идет о перекомпиляции всего проекта. А при инкрементальной компиляции их проросту не будет. Так что твоя экономия это секунд 40 растянутые на весь день. Ты реально каждый час прошляпливашь больше.
Блин. Я же написал при инкрементальной компиляции. Секунд 8-10 занимает именно сканирование зависимостей.
На Линуксе на моей машине для того же проекта — около секунды.
VD>Потом скорость компиляции куда больше зависит от компилятора. Так MS VS работает куда как быстрее GCC. Стало быть воспользовавшись Виндовс ты свой проект скомпилируешь банально быстрее.
Обычно как раз MSVC и компилирую, а сейчас еще на DMC подсел — он компилирует примерно в 5-10 раз быстре MSVC для отладочных билдов.
VD>А если выбросись свой С++ то вообще получишь возможность резко ускорить процпсс компляции.
Ant на Java-проекте из 18000 файлов тоже весьма заметно задумывается — те же 10 секунд на сканирование зависимостей.
VD>Только что зашел на свою рабочую машину (ишу с ноута) и провел слерственный экспермент. У меня есть каталог с RSDN Offline (переведенные в html сообщения с форумов РСДН). В каталоге содержится где-то 22.8 тысяч файлов. VD>Первое нажатие энтера в Винкомандере заставляет машину задуматься где-то на 2-3 секунды. После того как MFT кэшируется открытие каталога занимает менее секунды.
Ну напиши простенький тест, который откроет эти файлы и прочтет их содержимое. Увидишь о чем я говорю.
VD>У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не более чем под больного воображения.
Да, да. Иду вызывать экзорциста, чтобы изгнал дьявола из моего компьютера.
VladD2 wrote: > У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не > более чем под больного воображения.
"dir /Q /4 /S WINDOWS >nul" у меня работает 6 секунд. В каталоге
Windows: 1241 папок и 11163 файлов.
На разбросаных по всей FS include-файлах, половина которых evict'ится из
кэша между компиляциями — 10 секунд вполне нормальная цифра для NTFS.
Кстати, если тебе так нравится NTFS и Windows, то расскажи как сделать
аналог Линуксового laptop mode?
В laptop mode отключается винчестер (совсем) и работа идет только
через файловый кэш, и изменения в FS также накапливаются в памяти и
сбрасываются на диск через какой-то интервал (у меня стоит 15 минут).
Так как обычно работа идет только с определенным набором файлов — то
диск включается, фактически, только во время commit'ов изменений.
Здравствуйте, Cyberax, Вы писали:
C>Так же порядка 5-10 секунд. Обычно меняется один-два файла, которые надо перекомпилировать, а пересвязать исполняемый файл.
Понятно, значит 5 секунд из которых 10 занимает обращение к файлам.
Хорошо излагает — собака. Учитесь Киса... (с)
C>Блин. Я же написал при инкрементальной компиляции. Секунд 8-10 занимает именно сканирование зависимостей.
Не выдумывай.
C>На Линуксе на моей машине для того же проекта — около секунды.
Обнови значит драйверы. Или разберись с тем что у тебя конфигурации винды не так.
VD>>Потом скорость компиляции куда больше зависит от компилятора. Так MS VS работает куда как быстрее GCC. Стало быть воспользовавшись Виндовс ты свой проект скомпилируешь банально быстрее. C>Обычно как раз MSVC и компилирую, а сейчас еще на DMC подсел — он компилирует примерно в 5-10 раз быстре MSVC для отладочных билдов.
И как ты сравнивашь вайловые системы на VC c GCC?
C>Ant на Java-проекте из 18000 файлов тоже весьма заметно задумывается — те же 10 секунд на сканирование зависимостей.
Ищи проблемы в дровах или каких-то левых настройках сделанных тобой лично.
VD>>Только что зашел на свою рабочую машину (ишу с ноута) и провел слерственный экспермент. У меня есть каталог с RSDN Offline (переведенные в html сообщения с форумов РСДН). В каталоге содержится где-то 22.8 тысяч файлов. VD>>Первое нажатие энтера в Винкомандере заставляет машину задуматься где-то на 2-3 секунды. После того как MFT кэшируется открытие каталога занимает менее секунды. C>Ну напиши простенький тест, который откроет эти файлы и прочтет их содержимое. Увидишь о чем я говорю.
А зачем читать содержимое? Ты ведь об инкрементальной компиляции говоришь. Я правильно понял?
Полная компиляция проекта из 10К С++-файлов занимает поди пол часа или даже болше. Так? На них ни 10 ни 20 секунд значения иметь не убдут.
Я же тебе написал у меня открывается каталог. При этом считываются все характеристики файлов. В том числе и дата последнего изменения. Именно этим и ползуются все системы сборки. Занимает это не более секунды в Винкомандере.
Ну, ладно, сделаем простой эксперемент.
Вот простой тест эмулирующих поведение IDE:
using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Diagnostics;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Stopwatch timer = Stopwatch.StartNew();
string[] files = Directory.GetFiles(@"F:\Backup\rsdn.ru\WWW\Offline\Forum");
DateTime oldestTime = DateTime.Now;
foreach (string file in files)
{
DateTime dt = File.GetLastWriteTime(file);
oldestTime = dt > oldestTime ? dt : oldestTime;
}
Console.WriteLine(timer.Elapsed);
Console.WriteLine("В каталоге " + files.Length + " файлов.");
Console.WriteLine("Самый старый файл обновлялся " + oldestTime);
}
}
}
А вот его результат:
00:00:00.8381922
В каталоге 22824 файлов.
Самый старый файл обновлялся 03.07.2006 22:35:43
Файлов в двое больше чем ты описывашь. Код на дотнете и далек от оптимального. Но результат как-то совсем не подтверждает твоих слов.
В общем, или ты мягко говоря говоришь не правду, или у тебя какие-то локальные проблемы на машине, а ты свой опыт обобщаешь на всех окуражающих.
Кстати, заметь, у меня на машине никаких специальных настроект (типо отключения чего-то там не быстрого) не проводилось. Это штатная ХРюша.
VD>>У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не более чем под больного воображения. C>Да, да. Иду вызывать экзорциста, чтобы изгнал дьявола из моего компьютера.
Вызывай не вызвай. Но проблема в твоих личных руках. Ты просто не сумел добиться от своей машины нормальной работы. Или наоборот наставил разного дерьма которое и тормозит машину.
Конфигурация то у машины какая?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не >> более чем под больного воображения. C>"dir /Q /4 /S WINDOWS >nul" у меня работает 6 секунд. В каталоге C>Windows: 1241 папок и 11163 файлов.
Серьезно? Ну, тогда перестать мошейничать и убери опцию "/Q". Сразу станет пошустрее. У меня в виндовс 23К файлов и тест отрабатывает быстрее чем за секунду (когда информация закэширована). На ноуте где-то 17К файлов и тоже меньше секунды.
В общем, сдается мне, что дело не в машине. А в чьей-то честности.
Что можно доказать откровенными подлогами?
Ни одна система сборки проектов не занимается фигней вроде сбора информации о владельцах файлов. И уж темболее не будет превращать все это в текст и записывать в файл.
C>На разбросаных по всей FS include-файлах, половина которых evict'ится из C>кэша между компиляциями — 10 секунд вполне нормальная цифра для NTFS.
У тебя же была инкрементальная компиляция? Поди еще и прекомпилируемые заголовки включены?
Как же выходит, что нужно читать все иклюды?
В общем, заврался ты совсем. Извини, но мне уже надоело тратить на тебя время.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>"dir /Q /4 /S WINDOWS >nul" у меня работает 6 секунд. В каталоге > C>Windows: 1241 папок и 11163 файлов. > Серьезно? Ну, тогда перестать *мошейничать* и убери опцию "/Q". Сразу > станет пошустрее. У меня в виндовс 23К файлов и тест отрабатывает > быстрее чем за секунду (когда информация закэширована). На ноуте где-то > 17К файлов и тоже меньше секунды.
BJam внутри делает проверку, что файл можно открыть — это примерно
аналогично опции "/Q" (я как раз пытался ускорить BJam, заменяя открытие
файла на проверку ACLей).
Не веришь — смотри файл headers.c и hcache.c из исходников BJam.
> Ни одна система сборки проектов не занимается фигней вроде сбора > информации о владельцах файлов. И уж темболее не будет превращать все > это в текст и записывать в файл.
Вывод в текстовом файл — копейки по времени.
> C>На разбросаных по всей FS include-файлах, половина которых evict'ится из > C>кэша между компиляциями — 10 секунд вполне нормальная цифра для NTFS. > У тебя же была инкрементальная компиляция? Поди еще и прекомпилируемые > заголовки включены? Как же выходит, что нужно читать все иклюды?
А как еще определить, что именно нужно перекомпилировать?
Например, если я поменяю файл boost/filesystem/fstream.hpp, то нужно
будет перестроить половину проектов (включая и подключенный
boost::filesystem).
VladD2 wrote:
> В каталоге 22824 файлов. > Самый старый файл обновлялся 03.07.2006 22:35:43
Плоский каталог обычно обрабатывается быстро. Исходники же имеют ветвистую структуру. Создай дерево 5*5 каталогов с 5
файлами в листьях. Будет 15625 файлов. На винде такая хрень жутко тормозит, в линухе такое обрабатывается также как и
плоский каталог. (Естественно это верно при первом обращении, а не из дисковых кэшей).
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
VladD2 wrote: > C>Так же порядка 5-10 секунд. Обычно меняется один-два файла, которые > надо перекомпилировать, а пересвязать исполняемый файл. > Понятно, значит 5 секунд из которых 10 занимает обращение к файлам.
5-10 секунд занимает непосредственно сама компиляция (вызов cl+link),
после того как граф зависимостей уже построен.
> C>На Линуксе на моей машине для того же проекта — около секунды. > Обнови значит драйверы. Или разберись с тем что у тебя конфигурации > винды не так.
Драйверы чего обновлять? Все как поставилось с родного
установчного диска — так и стоит.
Конфигурация Винды и так уже накручена: отключены 8.3-имена, поставлены
настройки "большого кэша", отключено отслеживание времени последнего
доступа к файлам.
> C>Обычно как раз MSVC и компилирую, а сейчас еще на DMC подсел — он > компилирует примерно в 5-10 раз быстре MSVC для отладочных билдов. > И как ты сравнивашь вайловые системы на VC c GCC?
А это неважно. В сканировании зависимостей компилятор не участвует. Вся
разница может быть только в разном наборе sysinclude'ов (которые не
сканируются) или в разном наборе файлов из-за условной компиляции (на
пару файлов разница).
> C>Ant на Java-проекте из 18000 файлов тоже весьма заметно задумывается — > те же 10 секунд на сканирование зависимостей. > Ищи проблемы в дровах или каких-то левых настройках сделанных тобой лично.
На всех остальных машинах у нас в оффисе — примерно так же с коррекцией
на мощность процессора/скорость дисков.
> C>Ну напиши простенький тест, который откроет эти файлы и прочтет их > содержимое. Увидишь о чем я говорю. > А зачем читать содержимое? Ты ведь об инкрементальной компиляции > говоришь. Я правильно понял?
Для инкрементальной компиляции зависимости все равно нужно отслеживать.
Можешь спросить у eao197 (автор еще одной build-системы), если мне не
веришь.
> Полная компиляция проекта из 10К С++-файлов занимает поди пол часа или > даже болше. Так? На них ни 10 ни 20 секунд значения иметь не убдут.
Полная компиляция делается раз в день, там действительно не важны 10-20
секунд.
using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Diagnostics;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Stopwatch timer = Stopwatch.StartNew();
string[] files = Directory.GetFiles(@"c:/windows/system32");
DateTime oldestTime = DateTime.Now;
foreach (string file in files)
{
DateTime dt = File.GetLastWriteTime(file);
try
{
FileStream fl = File.OpenRead(file);
fl.Dispose();
} catch (IOException ex) { }
oldestTime = dt > oldestTime ? dt : oldestTime;
}
Console.WriteLine(timer.Elapsed);
Console.WriteLine("В каталоге " + files.Length + " файлов.");
Console.WriteLine("Самый старый файл обновлялся " +
oldestTime);
int a = 0;
}
}
}
> А вот его результат: > 00:00:00.8381922 > В каталоге 22824 файлов. > Самый старый файл обновлялся 03.07.2006 22:35:43
Машина — двухпроцессорный AMD64 с 4Гб памяти (нет у меня FW2 на моем
компьютере) и отключенными редиректором FS.
Теперь мой ход:
import os
DIR = '/var/lib/vpopmail/[хрумс]/Maildir/cur'
maxsize = 0
for f in os.listdir(DIR):
path = os.path.join(DIR, f)
fl = open(path,"rb")
fl.close()
sz = os.path.getsize(path)
if sz>maxsize: maxsize=sz
print"The biggest readable file is %d bytes." % maxsize
Результат:
root@scblinux:~/test-sp# time python test.py
The biggest readable file is 33748150 bytes.
real 0m0.118s
user 0m0.064s
sys 0m0.052s
root@scblinux:~/test-sp# ls /var/lib/vpopmail/[хрумс]/Maildir/cur | wc
9062 9062 244345
root@scblinux:~/test-sp# cat /proc/cpuinfo | grep "model name"
model name : AMD Athlon(tm) 64 Processor 3000+
root@scblinux:~/test-sp# cat /etc/issue.net
Debian GNU/Linux testing/unstable
root@scblinux:~/test-sp# cat /etc/fstab | grep "/ "
/dev/md2 / reiserfs notail 0 1
Cyberax wrote: > E:\Users\Cyberax\TestSpeed\TestSpeed\bin\x64\Debug>TestSpeed.exe > 00:00:02.1704177 > ? ???????? 5680 ??????. > ????? ?????? ???? ?????????? 7/4/2006 1:07:50 PM > Машина — двухпроцессорный AMD64 с 4Гб памяти (нет у меня FW2 на моем > компьютере) и отключенными редиректором FS.
Стоп! Числа могут быть неверными — машина могла быть под нагрузкой.
Правильные числа будут вечером, когда машину освободят.
AndrewVK wrote: >> > работают все доступные среды. И оно логично. > C>Можно пример таких сред? Я знаю, пожалуй, только OmniCore. > http://www.jcreator.com
И за ЭТО еще хотят денег? Нда...
Ну ладно, есть две современных Windows-only Java IDE.
AndrewVK wrote: > C>Ну ладно, есть две современных Windows-only Java IDE. > Заметь, эти ссылки тебе накидали люди, которые на Java не программируют.
Я на Java программирую, но искать себе геммороя в виде Windows-only IDE?
Нет уж...
AndrewVK wrote: > C>Я на Java программирую, но искать себе геммороя в виде Windows-only IDE? > C>Нет уж... > Речь не идет о твоих личных предпочтениях или уместности Windows-only > IDE. Речь о твоем высказывании > Ничто. Ничего, кроме того, что ни одна распространенная тулза разработки > для Windows на него не ориентирована.
Кстати, есть еще ключевое слово распространенная. Из
распространенных я зная: IDEA, Eclipse, NetBeans, Emacs/VIM. Больше я в
реальной жизни Java IDE не видел.
Здравствуйте, Cyberax, Вы писали:
C>AndrewVK wrote: >> C>Я на Java программирую, но искать себе геммороя в виде Windows-only IDE? >> C>Нет уж... >> Речь не идет о твоих личных предпочтениях или уместности Windows-only >> IDE. Речь о твоем высказывании >> Ничто. Ничего, кроме того, что ни одна распространенная тулза разработки >> для Windows на него не ориентирована. C>Кстати, есть еще ключевое слово распространенная. Из C>распространенных я зная: IDEA, Eclipse, NetBeans, Emacs/VIM. Больше я в C>реальной жизни Java IDE не видел.
K-Develop ещё есть в KDE. Нативный редактор для нескольких языков программирования. Чем-то похож на JEdit. Так же гибко настраивается на любой компилятор.
Здравствуйте, kan_izh, Вы писали:
_>VladD2 wrote:
>> В каталоге 22824 файлов. >> Самый старый файл обновлялся 03.07.2006 22:35:43 _>Плоский каталог обычно обрабатывается быстро. Исходники же имеют ветвистую структуру. Создай дерево 5*5 каталогов с 5 _>файлами в листьях. Будет 15625 файлов. На винде такая хрень жутко тормозит, в линухе такое обрабатывается также как и _>плоский каталог. (Естественно это верно при первом обращении, а не из дисковых кэшей).
Результат на моем каталоге E:\WINDOWS в коем 2574 подкаталогов:
00:00:01.2725374
В каталоге 23427 файлов.
Самый старый файл обновлялся 05.07.2006 09:37:49
А вот код теста (змемен каталог и выбрана другая перегружаенная фукнция учитывающая подкатлаоги):
using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Diagnostics;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Stopwatch timer = Stopwatch.StartNew();
string[] files = Directory.GetFiles(@"E:\WINDOWS", "*.*", SearchOption.AllDirectories);
DateTime oldestTime = DateTime.Now;
foreach (string file in files)
{
DateTime dt = File.GetLastWriteTime(file);
oldestTime = dt > oldestTime ? dt : oldestTime;
}
Console.WriteLine(timer.Elapsed);
Console.WriteLine("В каталоге " + files.Length + " файлов.");
Console.WriteLine("Самый старый файл обновлялся " + oldestTime);
}
}
}
Так что получи заслуженный минус.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
iZEN wrote: > C>Кстати, есть еще ключевое слово *распространенная*. Из > C>распространенных я зная: IDEA, Eclipse, NetBeans, Emacs/VIM. Больше я в > C>реальной жизни Java IDE не видел. > K-Develop ещё есть в KDE. Нативный редактор для нескольких языков > программирования. Чем-то похож на JEdit. Так же гибко настраивается на > любой компилятор.
Ну это по современным меркам уже не IDE, а просто редактор. Такими
темпами еще и FAR можно назвать (кстати, именно FAR был моей первой Java
IDE).
Здравствуйте, Cyberax, Вы писали:
C>5-10 секунд занимает непосредственно сама компиляция (вызов cl+link), C>после того как граф зависимостей уже построен.
Снова машейничашь?
Тоолько что у тебя 10 секунд занимал сбор зависимостей.
В общем, пудри мозги другим. Всего доброго...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>BJam внутри делает проверку, что файл можно открыть — это примерно C>аналогично опции "/Q" (я как раз пытался ускорить BJam, заменяя открытие C> файла на проверку ACLей).
Не аналогичен. Вот мой пример аналогичен. Проверка данты требует открытия файла.
/Q читает информацию о защите. Что в виндовс довольно медленная процедура.
C>Не веришь — смотри файл headers.c и hcache.c из исходников BJam.
Я тебе не верю. Зачем мне куда-то еще смотреть?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Результат на моем каталоге E:\WINDOWS в коем 2574 подкаталогов: > 00:00:01.2725374 > В каталоге 23427 файлов. > Самый старый файл обновлялся 05.07.2006 09:37:49
Заметь, уже 1.3 секунды. Умножь это число на 5 — получим порядка 7 секунд.
Еще надо сделать скидку на мой (скорее всего) более медленный ноутбук и
на то, что часть файлов может evict'ится из каталогов.
Кроме того, я только сейчас это заметил — при сканировании
include-файлов они ищутся по именам, что немного медленнее перечисления
findfirst/findnext'ом.
Здравствуйте, Cyberax, Вы писали:
C>Ну ладно, есть две современных Windows-only Java IDE.
И надо признаться, что это еще действительно редкий случай. В других областях Линукс вообще не поднимается. Меж тем из онли-Линус-солюшенс я знаю только дико убокий Миднайт-командер который и на фиг не уперся.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Кстати, есть еще ключевое слово распространенная. Из C>распространенных я зная: IDEA, Eclipse, NetBeans, Emacs/VIM. Больше я в C>реальной жизни Java IDE не видел.
И что VS значит не распростроненная?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>BJam внутри делает проверку, что файл можно открыть — это примерно > C>аналогично опции "/Q" (я как раз пытался ускорить BJam, заменяя открытие > C> файла на проверку ACLей). > Не аналогичен. Вот мой пример аналогичен. Проверка данты требует > открытия файла.
Мимо. Дата хранится в MFT вместе с именем и прочими метаданными. ACLи,
кстати, тоже хранятся в MFT.
> /Q читает информацию о защите. Что в виндовс довольно медленная процедура.
Почему, интересно? Информация хранится вместе с остальными метаданными.
Здравствуйте, VladD2, Вы писали:
VD>И надо признаться, что это еще действительно редкий случай. В других областях Линукс вообще не поднимается. Меж тем из онли-Линус-солюшенс я знаю только дико убокий Миднайт-командер который и на фиг не уперся.
Угу, а Emacs, KDE, Koffice, PostgreSQL -- они в это время погулять вышли.
Кстати, ничего из вышеперечисленного не является "онли-Линус-солюшенс". Они даже не Unix-only solutions.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2 wrote: > C>5-10 секунд занимает непосредственно сама компиляция (вызов cl+link), > C>после того как граф зависимостей уже построен. > Снова машейничашь? > Тоолько что у тебя 10 секунд занимал сбор зависимостей. > В общем, пудри мозги другим. Всего доброго...
Специально для тех кто не может понять:
Время сборки = время-на-сбор-завимостей + время-на-компиляцию.
C:\work\BuildPort>bjam
warning: Python location is not configured
warning: the Boost.Python library won't be built
Building Boost.Regex with the optional Unicode/ICU support disabled.
Please refer to the Boost.Regex documentation for more information
(and if you don't know what ICU is then you probably don't need it).
Couldn't find utypes.h in
...found 1377 targets...
...updating 3 targets...msvc.link bin\msvc-7.1\debug\link-static\BuildPort.exe
common.copy dist\BuildPort.exe
Скопировано файлов: 1.
common.copy dist\jam_lib.lib
Скопировано файлов: 1.
...updated 3 targets...
Здесь: сканирование зависимостей, и непосредственно
компиляция.
Так вот, сканирование зависимостей занимает ~10 секунд, а
непосредственно компиляция 5-10 секунд на типичных build'ах.
VladD2 wrote: > C>Кстати, есть еще ключевое слово *распространенная*. Из > C>распространенных я зная: IDEA, Eclipse, NetBeans, Emacs/VIM. Больше я в > C>реальной жизни Java IDE не видел. > И что VS значит не распростроненная?
А VS — это Java-IDE? Я там только J# видел.
KDE — оболочка для Линукса. Это все равно что желать запустить Эксплорер под виндовс.
К тому же врдя ли можно было бы считать потерей все эти продукты. А вот остаться без MS Office лично я не хотел бы. Да и MS SQL мне больше нравится чем Оракл. Да что там Оракл... Даже ВинКомандер не хочется менять на МидНайт.
E>Кстати, ничего из вышеперечисленного не является "онли-Линус-солюшенс". Они даже не Unix-only solutions.
Кстати, по ссылочкам походи. Все перечисленное можно запускать под виндовс. Тоько вот они как неуловимый Джо. На фиг никому не упали на Виндовс. Разве что Емакс который во всю исползуется его фэнами где угодно в том числе и под Виндовс.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Кстати, по ссылочкам походи. Все перечисленное можно запускать под > виндовс. Тоько вот они как неуловимый Джо. На фиг никому не упали на > Виндовс. Разве что Емакс который во всю исползуется его фэнами где > угодно в том числе и под Виндовс.
Вообще-то, Postgres/MySQL/OpenOffice сейчас под Windows вполне
используются.
Здравствуйте, VladD2, Вы писали:
E>>Кстати, ничего из вышеперечисленного не является "онли-Линус-солюшенс". Они даже не Unix-only solutions.
VD>Кстати, по ссылочкам походи. Все перечисленное можно запускать под виндовс. Тоько вот они как неуловимый Джо. На фиг никому не упали на Виндовс. Разве что Емакс который во всю исползуется его фэнами где угодно в том числе и под Виндовс.
Блин, ты вообще читаешь, что тебе пишут?
Я же ясно сказал, что перечисленные продукты (в том числе и Midnight Commander) не являются только Unix решениями. Из Unix-а вообще самые полезные вещи давно на другие платформы портировали. А из исключительно Linux-овых решений только какие-нибудь системные вещи и есть, вроде каких-нибудь утилит настройки роутинга или файловых систем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AndrewVK wrote: > C>А VS — это Java-IDE? Я там только J# видел. > Был такой продукт — Visual J++
А может археологическими раскопками не будем заниматься? В то время была
еще Visual Cafe for Java и куча прочих редакторов, которые сейчас на
титул IDE не тянут.
Кстати, было еще VisualAge for Java, но он был кроссплатформенный.
Здравствуйте, Streamer1, Вы писали:
K>> А я на веру ничего принимать не буду. Я попрошу библиографические ссылки, и постараюсь убедиться, что число получено из нескольких независимых источников.
S>ну дык берем теже "торсионные поля", открываешь гугль и тебе валится миллионы ссылок на "независимые" источники... ты принимаешь эту инфу достоверной?
У некоторых прикольных личностей (не будем показывать пальцем) замечены определённые трудности с адекватным восприятием русского языка. Интересно, с чего бы это? СВЧ переоблучали, наверное? С американских спутников?
Здравствуйте, Streamer1, Вы писали:
S>тогда чем вы можете объяснить свои категорические заявления, без ознакомления о чем (тобишь о каких условиях) речь идет?
Смешной человечек, я на порядки лучше тебя разбираюсь в той теме, на которую ты ссылаешься. Так что успокойся. Начни верхней головой думать. Может, лет через пять у тебя даже начнёт получаться.
Здравствуйте, Kolhoz, Вы писали:
K>>> А я на веру ничего принимать не буду. Я попрошу библиографические ссылки, и постараюсь убедиться, что число получено из нескольких независимых источников.
S>>ну дык берем теже "торсионные поля", открываешь гугль и тебе валится миллионы ссылок на "независимые" источники... ты принимаешь эту инфу достоверной?
K> У некоторых прикольных личностей (не будем показывать пальцем) замечены определённые трудности с адекватным восприятием русского языка. Интересно, с чего бы это? СВЧ переоблучали, наверное? С американских спутников?
так у тебя такая логика, потому что тебя СВЧ переоблучили?
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Kolhoz, Вы писали:
S>>тогда чем вы можете объяснить свои категорические заявления, без ознакомления о чем (тобишь о каких условиях) речь идет?
K> Смешной человечек, я на порядки лучше тебя разбираюсь в той теме, на которую ты ссылаешься. Так что успокойся. Начни верхней головой думать. Может, лет через пять у тебя даже начнёт получаться.
ваши высказывания черезчур выдают то обстоятельство, что вы ламер... Если ламера зацепить намеком на некомпетенцию, он точно также начнет изрыгать оскорбления и рассказывать что он такой супер-пупер кул-хацкер...
Не проявляйте свое ламерство, а учитесь — признание что чего то не знаешь это пол пути к знанию, а вот ваш путь — это только самоутверждение в качестве великого ламера...
Тот кто говорит не знает, тот кто знает не говорит.
Здравствуйте, Kolhoz, Вы писали: K>Здравствуйте, Streamer1, Вы писали:
K> Смешной человечек, я на порядки лучше тебя разбираюсь в той теме, на которую ты ссылаешься. Так что успокойся. Начни верхней головой думать. Может, лет через пять у тебя даже начнёт получаться.
Успокойтесь оба, а не то забаню обоих.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
VladD2 wrote:
> _>Плоский каталог обычно обрабатывается быстро. Исходники же имеют > ветвистую структуру. Создай дерево 5*5 каталогов с 5 > _>файлами в листьях. Будет 15625 файлов. На винде такая хрень жутко > тормозит, в линухе такое обрабатывается также как и > _>плоский каталог. (Естественно это верно при первом обращении, а не из > дисковых кэшей).
Ты это учитывал? Программу мне лень писать, но Far на каталоге windows "Quick view" в первый раз отрабатывает больше чем
за 20 секунд, а потом меньше секунды. (1594 файлов, 1588 каталогов).
> Результат на моем каталоге E:\WINDOWS в коем 2574 подкаталогов: > > 00:00:01.2725374 > В каталоге 23427 файлов. > Самый старый файл обновлялся 05.07.2006 09:37:49
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, 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> Людям надо быстро поправить брошюру и отдать ее в типографию, а потом бежать домой удовлетворять потребности из пирамиды Маслоу. Не надо кичиться своей нердностью. Она вполне хороша на своем месте, среди других нердов.
Мои ТеХники бегут домой гораздо быстрее чем твои по башке стукнутые тупые вордописцы.
Здравствуйте, Anton Batenev, Вы писали:
AB>>>1. Я хочу понять, чем эти два подхода так сильно отличаются (понять визуально [если не сложно, то скриншотики с подробными комментариями], поюзать, если возможно [URL для скачивания]). K>> Для mathview очень легко понять визуально разницу. Там DPS торчит из всех щелей.
AB>Что такое DPS?
Display PostScript. Красивейшая весч, всем весьма настоятельно рекомендую к ознакомлению.
Здравствуйте, Kolhoz, Вы писали:
K> А я не юниксоид. Попрошу не оскорблять.
Ишь ты какой. Это тебе обратно за вендузятников. K> Я ориентирован. На отборного потребителя. Умного, образованного.
Угу. Желаю вам обоим творческих успехов. K> Ну надо. Ну пусть он это всё и имеет. Только, пожалуйста, без меня. Я в эти идиотские игры не играю. Тошно-с.
Да он и так без тебя имеет. Расслабься. S>>И при этом желательно чтобы это было WYSIWYG. K> Это ваши больные, ущербные, убогие представления. Ничего общего с реальностью не имеющие. Мои подопытные пользователи TeX-а — это экономисты, биологи, филологи, переводчики, физики, программисты (самого низшего звена, даже PHP-шники попадались), секретарши без высшего образования.
Да ну прямо. Вон ты на два абзаца выше уже упомянул, что не всякий достоин стать твоим пользователем. K> Мои ТеХники бегут домой гораздо быстрее чем твои по башке стукнутые тупые вордописцы.
Еще одно такое оскорбление в адрес неопределенного круга пользователей и ты пойдешь в бан.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DarkGray wrote: > C>В Win я могу создать IStream (поток с поддержкой seek'а) над своими > C>данными, и отдать его rar'у (а лучше 7-zip'у). > Каким образом ты IStream передал в rar?
У него есть COM-интерфейс. Лучше взять 7-zip — у него тоже есть
COM-интерфейс и он вдобавок свободный.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Cyberax, Вы писали:
C>>А Reiser4FS на Винде есть? Или любая другая нормальная FS, которая не C>>торомзит?
VD>А меня и NTFS устравивает. Зачем мне искать от добра дотбра?
а не соизволят ли дорогие господа вмешаться мне в бурную дискуссию о КОП
Вопрос прост — почему ReGet Deluxe 4.2 (build 263) сохраняет на NTFS названия файлов с запрещенными символами типа ":",
которые потом удалить можно только через cmd
это артефакты от добра "КОП NTFS"?
Здравствуйте, Mamut, Вы писали:
E>>Можно ли сделать это стилями Word-а?
M>Ну, это не стили. Это меню Insert -> Reference -> Cross-Reference. Там, правда, свои заморочки есть
И заморочки заключаются в том, что такого в ворде сделать нельзя (или я не нашел, как).
Всегда будет писаться "на стр.". Ничего кастомизировать не получится.
Ворд в этом плане весьма отстойный, я с ним работал очень много (верстал книги).
И даже стили не спасают — все равно ворд умудряется работать с ними настолько криво...
Кстати, знатоки и любители ворда — как мне вставить в строку текста (в середину) картинку, чтобы ее нижний край был ниже baseline? Я способа так и не нашел.
Еще в защиту ТеХа — писал я как-то статью, и там у меня были постоянно встречалась (везде в тексте, не только в формулах) фигура типа "нечто, потом в нижнем индексе (subscript) сначала курсивом буква k, потом прямым болдом буква l со стрелкой (в смысле, вектор), а в верхнем индексе (superscript) плюсик)".
В ТеХе я сделал функцию, которая всасывала в себя один аргумент (упомянутое "нечто"), а выдавала всего описанного крокодила.
После чего я вызов этой функции ( синтаксически он выглядел типа \func{нечто} ) вставлял и в текст, и в формулы — и все было просто замечательно и крайне читабельно именно на уровне исходного кода.
Когда же какая-то конферения затребовала абстракт в ворде, и мне пришлось переписать то же самое в ворде — я проклял все на свете. На формулы по-человечески не сослаться (под ссылой имеется в виду номер формулы в скобках) — либо надо хардкодить ссылки, и тогда уже нельзя будет менять формулы местами, либо (если действовать через автонумерацию ворда) номера формул будут криво висеть, а не так, как положено по стандартам, потому что формулы — это встроенные объекты Equation.
А потом для другой конференции мне понадобилось поменять шрифт с 12 на 8. Представили, какой я имел секс со всеми объектами Equation? В Техе для этого потребовалось бы изменить цифру в одном только месте (а то и просто в параметре командной строки).
ну а если вспомнить про то, что ворд периодически перестает понимать, что это за объект (т.е. час назад ты работал с объектом Equation и мог его дабл-кликом начать редактировать, а теперь ворд просто пишет, что, мол, "это хз что за объект, и я знаю только, как его отображать, потому что у меня тут остался от него метафайл") — это автоматически означало, что сейчас мне придется эту формулу перенабрать. Насколько удобно набирать сложные формулы в Equation, знают все, кто с ним имел дело. MathType не особо лучше в этом смысле.
С другой стороны, в ТеХе весьма геморно делать вещи, заточенные именно под визуальное восприятие, типа презентаций или игр с картинками, на которые надо правильно наложить какой-нть текст в правильное место. Тут, конечно, WYSIWYG рулит, без вопросов.
Здравствуйте, Kolhoz, Вы писали:
K>Здравствуйте, Cyberax, Вы писали:
C>>Я уже давно понял, что делать распределенные или многопоточные системы C>>на чем-то кроме отсылки сообщений — это обычно гиблое дело.
K> Только понимать тут нечего — это тривиально доказуется формально.
можно ли развить тему более подробно? любопытно было бы послушать.
ironwit wrote: > K> Только понимать тут нечего — это тривиально *доказуется формально*. > можно ли развить тему более подробно? любопытно было бы послушать.
Все что дает MP — это отсутствие race-condition'ов, так как просто
отсутствуют разделяемые данные.
K> Не согласен. Если разработчики дизельных двигателей начнут их проектировать исходя из цвета и формы кузова автомобиля, под который делается движок, а так же при первоначальной оценке проекта обязательно учитывать обивку кресел — то это будет просто смешно.
Насчет обивки не знаю, а вот на форму авто закладываются, это точно. Потому что автоконцерн продает автомобили, а не дизели (именно).
K> GUI вторично всегда, даже в самом юзер-ориентированном проекте. И разработчик просто не имеет ни малейшего права выводить архитектуру приложения исходя из своих представлений о GUI. Такому разработчику в индустрии не место.
Индустрия большая, а самое главное — уже старая. Есть тонны юзеров, которые привыкли уже к чему-то особенному. Макет GUI разрабатывается сразу же еще и потому, что потребует затем времени на реализацию и "вылизывание", т.е. учатсвует в оценке необходимых ресурсов на разработку.
K> Так я и рассказываю. Не слушают-с. Сколько я этих GUI понаделал, преимущественно под Windows, и ну ни разу не приходилось применять их, вендовый стиль мышления.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не совсем так. Unix way (во всяком случае, в контексте этой дискуссии, как я её понимаю) не так мёртво завязан на синхронность вызовов. Что COM, что CORBA — одна и та же песня: синхронный вызов с непредсказуемой длительностью, с помощью которых ещё и эмулировать messaging приходится.
Ну вообще-то в CORBA можно описать асинхронные вызовы.
В CORBA-way делают так:
A --- msg_to_call_func(callback) -->
тишина...
callback <--- msg_with_result
Ведь тебе по-любому надо как-то заниматься диспечеризацией ответных сообщений, наличие callback делает это автоматически. Если же прямой вызов A-->B был асинхронным, то такая модель IMHO получается самой удобной для программирования того, о чем ты говоришь, ибо стандарты CORBA решают за разработчика кучу вещей, начиная от разбора/компоновки сообщений, диспечеризации и заканчивая балансировкой нагрузки на серверной стороне (с поддержкой пулов тредов и прочих технических "мелочей", которые вовсе не мелочи).
ГВ>Ну и поскольку здесь не притягивается семантика понятия "вызов функции" (имя функции, параметры, результат), то можно обойтись более простыми средствами, не так сильно влияют стереотипы. Или, говоря порезче: меньше лишнего хлама под ногами болтается.
Фиг его знает. Ведь любой свой протокол надо специфицировать. А IDL с коменнтариями сама по себе является неплохой докой.
ГВ>Опять таки, любой вызов DCOM/CORBA может завершиться исключением, а это уже требует в обязательном порядке обкладывать их обработкой исключений, с messaging всё проще — мы сразу честно признаёмся себе, что длительность вызова предсказать нельзя и ориентируемся на модель: "ждём сообщение", а не "должно сработать!".
Это верно для синхронных вызовов.
ГВ>Эмулировать RPC с помощью messaging — запросто (он и так на нём построен ), обратное — уже не так легко (минимум два варианта: polling или callback), плюс обязательная дополнительная загрузка канала связи. В случае callback (для CORBA) ещё нужно вставлять в клиенскую часть сугубо серверные приблуды итэдэ итэпэ.
В момент инициализации ORB-а добавить 5-6 лишних строк для установки его серверных св-в. В мессейджинге тебе ведь тоже надо как-то озаботиться приемом сообщений. В CORBA можно запустить ORB в отдельном потоке, либо регулярно вызывать у него нечто вроде do_messages(). Т.е. ничем не хуже обслуживание сокетов. Да еще код попереносимей будет.
ГВ> А простой messaging по IP: сокеты плюс простенькая сериализация. Да и то, в случае C можно структуры данных почти без изменений гонять (диспетчеризация только нужна и решение конфликта endian-ов).
Да, именно, речь о масштабировании. Если система взаимодействующих процессов предназначена для работы на одной машине, то от очень многого можно отказаться, и сэкономить на размерах бинарных исполняемых образов. Тогда вариант с перегонкой структур С по значению работает прекрасно.
ГВ>Одним словом, messaging — базовый механизм, на нём уже можно сделать всё.
От требований задачи зависит. Если вдруг начнет получаться, что самописный messaging превращается в CORBA или COM, то понятно, что делать надо.
Здравствуйте, Cyberax, Вы писали:
C>Кроме того, я только сейчас это заметил — при сканировании C>include-файлов они ищутся по именам, что немного медленнее перечисления C>findfirst/findnext'ом.
Ты спутал НТФС с ФАТ32 В нем перебор делается быстрее чем поиск по имени.
Как раз по именам в НТФС ищется быстрее, нежели перебором findfirst/findnext.
Все оттого, что поиск в дереве выполняется быстрее перебора всех элементов.
> Самый старый файл обновлялся 05.07.2006 09:37:49
Заметь, уже 1.3 секунды. Умножь это число на 5 — получим порядка 7 секунд.
С учетом твоего высказывания выше, можно 7 помножить еще на 1000 и прибавить 345, шоб больше було
>>> > XPCOM просто самопальный клон КОМ-а который можно использовать в любом >>> > компиляторе С++ при наличии соотвествующих библиотек. >> C>А тулзы для работы с его библиотеками типов, создания wrapper'ов по типу >> C>ATLевских, всякие аналоги ATL/MFC Trace Tool? >> А что с Цигвином оно не работает? C>XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что C>кроме тулзов из Mozilla для XPCOM больше ничего почти и нет.
Plutonia Experiment wrote: > Ты спутал НТФС с ФАТ32 В нем перебор делается быстрее чем поиск по имени. > Как раз по именам в НТФС ищется быстрее, нежели перебором > findfirst/findnext. > Все оттого, что поиск в дереве выполняется быстрее перебора всех элементов.
Ничего я не перепутал. Почитай лучше про алгоритм "танцующих деревьев" в
Reiser4.
NTFS — это хорошая система для 90-х годов, но сейчас она уже устарела.
>> Самый старый файл обновлялся 05.07.2006 09:37:49 > Заметь, уже 1.3 секунды. Умножь это число на 5 — получим порядка 7 секунд. > С учетом твоего высказывания выше, можно 7 помножить еще на 1000 и > прибавить 345, шоб больше було
Мне просто лень было делать более точные замеры. Я уже как-то сюда писал
мини-бенчмарк: http://rsdn.ru/Forum/?mid=1710544
Plutonia Experiment wrote: > C>Драйверы *чего* обновлять? Все как поставилось с родного > C>установчного диска — так и стоит. > Ты винду и лялих запускаешь на одном и том же медленном ноутбуке ?
Ага. Хотя не такой уж он и медленный — я специально поставил винчестер
на 7200RPM.
Plutonia Experiment wrote: > C>Кстати, если тебе так нравится NTFS и Windows, то расскажи как сделать > C>аналог Линуксового laptop mode? > Элементарно. 2 гига памяти и отключаешь своп.
Мимо тазика. Каждый раз когда ты будешь жать ctrl-s в редакторе у тебя
будет происходить запись на диск, а значит диск должен работать.
Laptop-mode позволяет ВООБЩЕ выключить диск (его двигатель физически
останавливается) и накапливать изменения в памяти, а потом сбрасывать
одним куском.
Plutonia Experiment wrote: >> > *C>А тулзы для работы с его библиотеками типов, создания wrapper'ов > по типу** >> > C>ATLевских, всякие аналоги ATL/MFC Trace Tool?* >> > А что с Цигвином оно не работает? > *C>XPCOM (как и сам COM) может работать с чем угодно — смысл в том, что > C>кроме тулзов из Mozilla для XPCOM больше ничего почти и нет.* > Выделил сообщения. Не могу понять логики
XPCOM — это языко-независимая система по своему дизайну, но де-факто с
ней работают только тулзы от Mozilla.
Здравствуйте, Cyberax, Вы писали:
C>Plutonia Experiment wrote: >> Ты спутал НТФС с ФАТ32 В нем перебор делается быстрее чем поиск по имени. >> Как раз по именам в НТФС ищется быстрее, нежели перебором >> findfirst/findnext. >> Все оттого, что поиск в дереве выполняется быстрее перебора всех элементов. C>Ничего я не перепутал. Почитай лучше про алгоритм "танцующих деревьев" в C>Reiser4.
при сканировании
include-файлов они ищутся по именам, что немного медленнее перечисления
findfirst/findnext'ом.
Узнаешь автора этих строк ? Так вот, это утверждение ложно для системы НТФС(и рейзер4) и истинно для фат32. Так понятнее ?
Здравствуйте, Cyberax, Вы писали:
C>Laptop-mode позволяет ВООБЩЕ выключить диск (его двигатель физически C>останавливается) и накапливать изменения в памяти, а потом сбрасывать C>одним куском.
Запись все равно будет, когда приложениям понадобится доп. память. В чем смысл этого ?
Plutonia Experiment wrote: > C>Laptop-mode позволяет ВООБЩЕ выключить диск (его двигатель физически > C>останавливается) и накапливать изменения в памяти, а потом сбрасывать > C>одним куском. > Запись все равно будет, когда приложениям понадобится доп. память. В чем > смысл этого ?
Вот если понадобится — тогда и запишется. Например, на 1Гб памяти
с CompressedCache патчем компиляция ядра Линукса проходит без единого
касания диска.
Plutonia Experiment wrote: > C>Ничего я не перепутал. Почитай лучше про алгоритм "танцующих деревьев" в > C>Reiser4. > при сканировании > include-файлов они ищутся по именам, что немного медленнее перечисления > findfirst/findnext'ом.
Для КАЖДОГО файла нужно сделать поиск по имени — получаем время
N*log(N), где N — число файлов.
В случае с findfirst/findnext нужно просто один раз перебрать все файлы,
что дает время N. Это и имелось в виду.
> C>Мне просто лень было делать более точные замеры. Я уже как-то сюда писал > C>мини-бенчмарк: http://rsdn.ru/Forum/?mid=1710544
Здравствуйте, Cyberax, Вы писали:
C>Вот если понадобится — тогда и запишется. Например, на 1Гб памяти C>с CompressedCache патчем компиляция ядра Линукса проходит без единого C>касания диска.
А для чего это ? что бы на форум сюда прийти и сказать об этом ?
Проекты, с которыми я работаю, создают временных файлов и всякой бряни от гигабайта и до трех. Не пойму, чем это режим мне лично поможет.
Здравствуйте, Cyberax, Вы писали:
C>Plutonia Experiment wrote: >> C>Ничего я не перепутал. Почитай лучше про алгоритм "танцующих деревьев" в >> C>Reiser4. >> при сканировании >> include-файлов они ищутся по именам, что немного медленнее перечисления >> findfirst/findnext'ом. C>Для КАЖДОГО файла нужно сделать поиск по имени — получаем время C>N*log(N), где N — число файлов.
C>В случае с findfirst/findnext нужно просто один раз перебрать все файлы, C>что дает время N. Это и имелось в виду.
Вобщем разъясни подробно, что ты имел ввиду когда говорил следующее
"при сканировании include-файлов они ищутся по именам, что немного медленнее перечисления findfirst/findnext'ом"
Plutonia Experiment wrote: > C>Вот *если* понадобится — тогда и запишется. Например, на 1Гб памяти > C>с CompressedCache патчем компиляция ядра Линукса проходит без единого > C>касания диска. > А для чего это ? что бы на форум сюда прийти и сказать об этом ? > Проекты, с которыми я работаю, создают временных файлов и всякой бряни > от гигабайта и до трех. Не пойму, чем это режим мне лично поможет.
"А для чего это ? что бы на форум сюда прийти и сказать об этом ?" (c) ты.
Для меня этот режим очень полезен, например. Так у меня не создаются
гигабайты временных файлов. Для многих других тоже может быть полезно.
Plutonia Experiment wrote: > C>В случае с findfirst/findnext нужно просто один раз перебрать все файлы, > C>что дает время N. Это и имелось в виду. > Вобщем разъясни подробно, что ты имел ввиду когда говорил следующее > "при сканировании include-файлов они ищутся по именам, что немного > медленнее перечисления findfirst/findnext'ом"
Сравнивалось однократное линейное сканирование каталога и многократный поиск в нем по имени.
Здравствуйте, Cyberax, Вы писали:
>> C>Мне просто лень было делать более точные замеры. Я уже как-то сюда писал >> C>мини-бенчмарк: http://rsdn.ru/Forum/?mid=1710544
>> Это не бенч. Это подгон под нужные результаты. C>Хочешь сказать, что цифры неправильные? Ну давай еще потестим.
Я хочу сказать, что сначала были цифры, а потом появился тест.
Такой тест, как компиляция, ничего не показывает. А именно ее ты пытался эмулировать.
Здесь узкое место не файловая система, а процессор.
Ну быстрее тут рейзер4 и что с того ?
Теперь по тесту.
Во первых, сравнивается только в одинаковых условиях. у тебя этого нет.
Во вторых, тест не полный — нужны тесты с различными размерами файлов — это очень важно.
Так вот, уважаемый, обе файловые системы заточены под ОС, а не абстрактые реализации неких хороших идей.
В силу особенностей линукса файловое пространство имеет одни особенности, НТ-ХП — другим способом (количество файлов, размеры файлов, особенности работы с файлами и тд и тд).
И файловые системы сделаны так, что бы в этих случаяъ и давать максимальную производительность.
С учетом того, что рейзер4 появилась на 10 лет позже НТФС, очевидно, что в рейзер4 учли опыт и ошибки НТФС. Следовательно можно ожидать что рейзер4 будет пошустрее. Но не в разы, как ты показал.
Теперь один вопрос — рейзер4 уже стал стабильной или все еще падает ?
А то журналирование есть, а данные теряются
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Теперь один вопрос — рейзер4 уже стал стабильной или все еще падает ? PE>А то журналирование есть, а данные теряются
Когда я на своей текущей работе спросил, а почему везде стоит ext3 ведь народ пишет что reiser4 быстрее... мне ответели:
reiser4 перманентно не стабилен.
Все.
Кроче reiser4 может выполнять какието операции хоть в 1000 раз быстрее но если она дает не верные результаты то она не работает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > Когда я на своей текущей работе спросил, а почему везде стоит ext3 ведь > народ пишет что reiser4 быстрее... мне ответели: > reiser4 перманентно не стабилен.
А я у сантехника спросил об окнах — он мне сказал, что лучше ставить
пластиковые. Сейчас вот думаю, как их заказать у Microsoft.
> Все. > Кроче reiser4 может выполнять какието операции хоть в 1000 раз быстрее > но если она дает не верные результаты то она не работает.
У меня на ноуте работает уже очень долгое время без проблем. На двух
корпоративных серверах — тоже без нареканий.
Reiser4 — пока в нестабильной ветке Линукса (-mm ядро), скоро собираются
мигрировать в mainline.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Quintanar, Вы писали:
Q>>Так поднапрягите воображение. На COM и .NET мир клином не сошелся. Q>>У программистов Windows есть понятная склонность считать технологии МС верхом человеческой мысли. А то, что эти технологии меняются как в калейдоскопе их не заботит. Unix консервативен, в его мире книги Стивенса, вышедшие в начале 90-х, до сих пор сохраняют свою полезность и эта консервативность не мешает делать крупные проекты.
VD>Забавно, что есть много слов. Даже трое согласных с ними. И ни грамма по КОП.
да, ты крут. А вот мне нравятся книги стивенса, хоть я и не любитель иниксоидов и не любитель пиара МС.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, VladD2, Вы писали:
VD>>К сведению, к Виндовс отосятся кроме ХРюши еще Мобаил- и ЦЕ-версии которые работают на куче разнообразных железок. VD>>Но это к делу не относится. Я говорил об истории. Дело в том, что архитектура NT была сформирована еще до того как появились первые сообщения о Линуксе. И формиловалась она под влиянием очень известного человека в мире миникомпьютеров. NT изначально была архитектурно более гибка чем Линукс. А линукс как раз послал к чертям все завоевания научной мысли тех лет и породил монолитную архитектуру смело шагнувшую на много лет назад. ZEN>Выделенное — чистый, незамутнённый бред. ZEN>Первое упоминание о Linux датировано августом 1991 года,
Здравствуйте, IID, Вы писали:
IID>а NT начали делать в 89ом.
neiroman, ты не согласен что Microsoft начала делать NT в 1989 году, пригласив для этого Дейва Катлера ?
Гугл тебе в помошь по кейворду "Windows NT 1989"
Вот что пишет Дэвид Соломон Кстати, он сотрудник MS и соавтор (с Марком Руссиновичем) книги Inside Windows NT (а также последущих изданий Inside Windows 2000, Inside Windows 2003 server
Когда в 1989 году Microsoft приступила к разработке Windows NT, было выдвинуто несколько ключевых требований к новой операционной системе. Это должна была быть полностью 32-разрядная ОС, способная работать на многочисленных аппаратных платформах с разной архитектурой.
NT задумывалась как распределенная, клиент-серверная ОС, поддерживающая симметричные многопроцессорные аппаратные платформы. Сегодня разработчики наносят завершающие штрихи в своем новом творении — Windows NT 5.0 [оригинальная статья была опубликована в IEEE Computer до того, как Microsoft объявила новое название своей ОС — Windows 2000 — Прим. перев.], однако теперь, почти десять лет спустя, когда компания вносит завершающие штрихи в свое творение, можно с уверенностью сказать, что фундаментальные основы архитектуры NT в версии 5.0 не были изменены.
) ?
1.1.4 stable rev. 510
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Если нам не помогут, то мы тоже никого не пощадим.
