>то есть они всё таки есть? :D

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

>IIRC, в Plan9 самое главное - это 9P

Ну может быть. Я перестраховывался.

>Они и в Unix не являются таковыми.

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

>(shell давно не является основным средством программирования)

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

>К библиотекам доступ через Си API

В винде тоже. Она не юниквей.(И не из-за качества реализации модульности)

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

Надо же, тебе уже и про регекспы кто-то рассказал! Вах-вах-вах!

> ты посчитай нагрузку на цпу, ага.

Ну так ты мне предъявишь апплет, в котором это важно или как?

>> Прочитать бинарный блоб, разобрать его по составляющим, обратить при надобности порядок байт, запихать это в память (а в некоторых архитектурах за неправильный alignment бюьт по почкам SIGBUS-ом), а потом взлететь --- совсем не тривиальная операция.
> все это гораздо быстрее, чем распарсить строку и уже сделано в либе d-bus

Говно эта твоя либа. И из-за бинарного формата и из-за реализации.

> про порядок байт - это ты бугага написал, в локальной шине такого нет, а по сети - напиши код, который твой текстовый уникод переставлять байты в правильный порядок. И удавись
> за перл про выравнивание данных в IPC тебе отдельное спасибо. Поржал.

Молодец, гордись своей серостью дальше.

>> Про то, что бинарный поток не грепабелен, нечитаем
> нахрена его грепать и читать? Ты tcp-пакеты грепаешь и читаешь?

Для отладки в любом месте и в любое время. Хотя смысл тебе это объяснять, ты ж программ не пишешь.

> А вот тут как раз сказывается отсутствие мыслей о типичных use case-ах. Покажешь мне вполне типичный по твоему мнению апплет, гоняющий гигабайты данных через IPC?
> апплет тут совершенно ни причем. d-bus - шина _универсальная_. Если ты хочешь отдельный велосипед для апплетов - то лучше сразу убейся, это говно, когда в системе дефакто десятки несовместимых между собой IPC мы уже проходили.

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

>Молодец, гордись своей серостью дальше.

ты бы хоть почитал, что такое SIGBUS и какое отношение оно имеет к IPC. Позорище, мля

>Для отладки в любом месте и в любое время. Хотя смысл тебе это объяснять, ты ж программ не пишешь.

т.е бинарность tcp/ip грепать тебе не мешает. А что ты тут выступаешь тогда? =)

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

ты вообще в курсе зачем dbus делался? Походу нет. Ну так иди учи матчасть. С ice и mpi он его тут сравнивает. Бугагец полный.

>активно используются для связи между сервисами/драйверами/по

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

>"практически не используются"

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

>Ы?

Что "Ы?". Самый сложный и используемый софт между прочим. Хотя я не любитель КОМо подобного и защищать это не буду.

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

знаешь, в юниксе тоже пайпы не обязательно текст, вообще-то. mplayer например, умеет читать фильму с stdin и показывать.

кто вообще сказал, что пайпы - это только текст? gaa? ну так он известный поциент :)

>> Unix shell и пайпы - это просто первая, самая известная реализация юниксвея :)

> Зато она имеет самую надёжную изоляцию.

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

> ты бы хоть почитал, что такое SIGBUS и какое отношение оно имеет к IPC. Позорище, мля

Вырывать фразы из контекста ты тоже умеешь. В контексте всё ясно, пояснять я не намерен.

> ты вообще в курсе зачем dbus делался? Походу нет. Ну так иди учи матчасть. С ice и mpi он его тут сравнивает. Бугагец полный.

Гек, ты опять в своём репертуаре. Невежество, тупость и наглость так и прут.

Найди себе кого-нибудь чтоб пободаться, а мне надоело.

>кто вообще сказал, что пайпы - это только текст? gaa? ну так он известный поциент :)

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

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

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

>> Они и в Unix не являются таковыми.

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

Даже в старом Unix были программы, которые не через пайпы общались - как минимум библиотекарь и линкер :) Ну и демоны, естественно - от telnet до uucp. Так что работа с пайпами является _требованием_ только к довольно узкому классу программ, предназначенных для запуска в конвейерах shell. Для любой долгоживущей программе пайпы не являются необходимыми.

Да, и еще... Named Pipes венды - это не Unix pipes, а скорее Unix sockets.

>Вырывать фразы из контекста ты тоже умеешь. В контексте всё ясно, пояснять я не намерен.

нуну. Ты упомянул SIGBUS в контексте IPC, к которому SIGBUS ну никакого отношения не имеет =)))

>Гек, ты опять в своём репертуаре. Невежество, тупость и наглость так и прут.

т.е. по существу тебе ответить нечего? Слив защитан, сынок =)

ну и чтобы тебе совсем мозги прочистить - почитай про dbus-monitor и предложи решение для апплета, отключающего скринсейвер по клику. Да, интерфейс отключения скринсейвера (как и интерфейс управления power-manager, network-manager и прочими) - висит на dbus. А потом удавись, осознав свою безграмотность =)

Между тем, всем советую заценить Fortress. Там по дефолту воплощение отделено от интерфеса.

> Да, и еще... Named Pipes венды - это не Unix pipes, а скорее Unix sockets.

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

>> О_О!!!! Разве?! А с чего я взял что он на tcl/tk? Нет народ, точно вам говорю - склероз у меня. Или маразм? Или разом?!
> Разве. Точно. Разом.

Подозреваю что именно это именуется ЛОР'ом Головного Мозга. Пора мне уже завязывать с постоянным обитанием тут.

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

IIRC, именно так.

> Подозреваю что именно это именуется ЛОР'ом Головного Мозга. Пора мне уже завязывать с постоянным обитанием тут.

Ты ещё не понял, что отсюда уйти невозможно?

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

никакой это не узкий класс программ. Раньше этот класс программ основным набором инструментов пользователя. Но потом юникс умер. Но текст остался основным интерфейсом для многих аспектов. /proc к примеру появился после смерти юникса. К тому же этим узким набором программ до сих пор пользуются. Много ли пользователей линукса для поиска будет пользоваться гуйнёй вместо find . -print0 | xargs -0 grep -l "something" ? Сколько воплей когда кто-то выходит с предложением упразнить текстовые конфиги ?

Этот узкий класс программ это и есть юникс в современном линуксе. Всё остальное это уже не юникс и не юниквей.

>Много ли пользователей линукса для поиска будет пользоваться гуйнёй вместо find . -print0 | xargs -0 grep -l "something" ?

Много ли пользователей линукса будет конвертировать 100 raw в tiff c помощью меню? Или деуадиофилизировать большую дискографию данную в виде cue + ape?

> Этот узкий класс программ это и есть юникс в современном линуксе. Всё остальное это уже не юникс и не юниквей.

"десктопный линупс" и "серверной линупс" --- совершенно разные вещи. И если первый состоит из программ, которые переписываются каждые 5 лет, то второй вполне себе юникс.

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

> никакой это не узкий класс программ.

Узкий. И кроме него, были (и есть) другие классы програм.

> Раньше этот класс программ [был] основным набором инструментов пользователя

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

> юникс умер

> этим узким набором программ до сих пор пользуются

> это и есть юникс в современном линуксе

Ааа, DEAD WALK!!!!1111 Так юникс умер или как?

> Ааа, DEAD WALK!!!!1111 Так юникс умер или как?

Юникс Шрёдингера.

> Много ли пользователей линукса будет конвертировать 100 raw в tiff c помощью меню? Или деуадиофилизировать большую дискографию данную в виде cue + ape?

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

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

> Ааа, DEAD WALK!!!!1111 Так юникс умер или как?

В десктопном линупсе юникс умер.

But the day Linux gives the Mac diagnostic that you can't open a file because you don't have the application is the day Linux becomes non-Unix.

-- Doug McIlroy

>Узкий.

Не узкий. Для админчиков к примеру основной.

>были (и есть) другие классы програм.

Они были не юниквей. Они были просто программами.

>Ааа, DEAD WALK!!!!1111 Так юникс умер или как?

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

Не будут же они заменять уже работающие текстовые интерфейсы и "неузкий" набор программ, только от того что идеология "текст и потоки" работала только в 70ых, и разумеется не подходит как общая сегодня ? Да и потом оказалось _дешевле_ взять юникс и добавить в него костылей, чем разрабатывать новые среды вроде чего-то обьектного Squeak'а подобного индустриального качества.

> Не будут же они заменять уже работающие текстовые интерфейсы и "неузкий" набор программ, только от того что идеология "текст и потоки" работала только в 70ых, и разумеется не подходит как общая сегодня ? Да и потом оказалось _дешевле_ взять юникс и добавить в него костылей, чем разрабатывать новые среды вроде чего-то обьектного Squeak'а подобного индустриального качества.

Из этого следует, что он всё-таки жив, не так ли? UNIX --- это платформа. А платформа жива, пока на неё что-то опирается.

От того что swappable модульности доступной пользователю нет, или от того что иксы юзают shared кучу, а не текстовую сериализацию картинки + потоки ?

>But the day Linux gives the Mac diagnostic that you can't open a file because you don't have the application is the day Linux becomes non-Unix.

Смотреть картинки в консоли ?

>>Узкий.

>Не узкий. Для админчиков к примеру основной.

Ты специально путаешь широту и частоту?

>>были (и есть) другие классы програм.

>Они были не юниквей. Они были просто программами.

Интересный подоход - взять из Unix набор программ, объявить их Ъ, потом объявить их идеологически мертвыми.

> Идеологически умер конечно.

Ы. Определи понятие "идеологической смерти", а?

> От того что swappable модульности доступной пользователю нет, или от того что иксы юзают shared кучу, а не текстовую сериализацию картинки + потоки ?

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

>> But the day Linux gives the Mac diagnostic that you can't open a file because you don't have the application is the day Linux becomes non-Unix.
> Смотреть картинки в консоли ?

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

Я юниксовое поведение к своему линупсу приделал так:
$ cat .mailcap
application/octet-stream; gview -bf '%s'; edit=gvim -bf '%s'; compose=gvim -bf '%s'; test=test "$DISPLAY" != ""
application/octet-stream; view -b '%s'; edit=vim -b '%s'; compose=vim -b '%s'; needsterminal

:)

> в _юниксе_ форматы файлов читабельны для человека

Ага, ага. Осбенно экзешники, объектные файлы, архивы tar, сжатые файлы...

>Из этого следует, что он всё-таки жив, не так ли?

Я говорю про идеологию. Идеология умирает тогда, когда очевидно что с помощью неё не достичь желаемого(скриптование и взаимозаменяемость модулей [с твоих же слов]) в большинстве случаев.

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

>UNIX --- это платформа.

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

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

Ну дык это не юникс вей. Если я скажу среднему лоровцу что PowerShell это попытка юниквея - они рассмеются мне в лицо.

По крайней мере чтобы это хоть как-то стало юниксвеем, нужно куда-то вставить слово "текст". Без него никак.

За такой "юниквей" я двумя руками за.

>Почему ж в консоли? В просмотрщике

Ну это уже предел тролления на самом деле. Сконвертировал в hex, и пожалуйста "Открывай" в виме. Только большинство нормальных людей это открытием не считают.

>> в _юниксе_ форматы файлов читабельны для человека
> Ага, ага. Осбенно экзешники, объектные файлы, архивы tar, сжатые файлы...

Это специальные случаи. К слову, чем тебе "экзешники" с шебангом #!/usr/bin/python не нра?

>> От того, что он не скриптуем в любой точке и модули в нём не взаимозаменимы, да.
> Ну дык это не юникс вей. Если я скажу среднему лоровцу что PowerShell это попытка юниквея - они рассмеются мне в лицо.

Там та же проблема с потоками, что и в досе: сначала накапливается, потом отдаётся следующему. То есть там find | grep невозможен в принципе без специальных ухищрений. Максимум можно получить "find > tmp; grep tmp".

> По крайней мере чтобы это хоть как-то стало юниксвеем, нужно куда-то вставить слово "текст". Без него никак.

Зачем? На платформе windows.net универсальным типом данных является Object.

>> Почему ж в консоли? В просмотрщике
> Ну это уже предел тролления на самом деле. Сконвертировал в hex, и пожалуйста "Открывай" в виме. Только большинство нормальных людей это открытием не считают.

Ну то есть ты и открытие tex-файла "открытием" не считаешь? А он ведь совсем не wysiwyg.

>>> в _юниксе_ форматы файлов читабельны для человека

>> Ага, ага. Осбенно экзешники, объектные файлы, архивы tar, сжатые файлы...

>Это специальные случаи.

Специальный случай - это как раз текст ;)

> К слову, чем тебе "экзешники" с шебангом #!/usr/bin/python не нра?

С /usr/bin/python - очень нравятся. Но это скрипты, а не бинари :)

> Там та же проблема с потоками, что и в досе: сначала накапливается, потом отдаётся следующему. То есть там find | grep невозможен в принципе

Пруфлинк или GTFO.

>> Из этого следует, что он всё-таки жив, не так ли?
> Я говорю про идеологию. Идеология умирает тогда, когда очевидно что с помощью неё не достичь желаемого(скриптование и взаимозаменяемость модулей [с твоих же слов]) в большинстве случаев.

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

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

С помощью юниксвея (а не "элементарного изложения") он уже реализован. Рассмотрим konqueror: доставанием файла по http занимается отдельный компонент VFS (kio_http), отрисовкой --- тоже отдельный компонент (khtmlpart). Сам konqueror только соединяет их вместе. И их можно отрывать друг от друга и комбинировать с другими вещами.

> графический редактор,

Авторы плагинного и скриптового гимпа зашлись диавольским хохотом.

> файловый менеджер,

Рассмотрим mc. Львиная доля его функциональности (VFS) реализована именно шеллопайпово.

> http сервер, итп c сохранением "скриптования модульности взаимозаменяемости для всех в одном пространстве".

Про CGI ты тоже совсем ничего не сялшал?

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

Только вот жить в эту пору прекрасную уж не придётся ни мне ни тебе :)

>> Там та же проблема с потоками, что и в досе: сначала накапливается, потом отдаётся следующему. То есть там find | grep невозможен в принципе
> Пруфлинк или GTFO.

Я смотрел, что там возвращает аналог find-а. Это List<FileObject>. Был бы iterable --- было бы интересно. А так тот же дос.

>>> Ага, ага. Осбенно экзешники, объектные файлы, архивы tar, сжатые файлы...
>> Это специальные случаи.
> Специальный случай - это как раз текст ;)

Так бодаться можно бесконечно.

>> К слову, чем тебе "экзешники" с шебангом #!/usr/bin/python не нра?
> С /usr/bin/python - очень нравятся. Но это скрипты, а не бинари :)

Но они же исполняются. Чем не "экзешники"?

>Там та же проблема с потоками, что и в досе: сначала накапливается,

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

>Object.

Object это не тип данных. Object это Object.

>Ну то есть ты и открытие tex-файла "открытием" не считаешь?

А причём здесь tex-файл ? Он изначально предназначен для работы с ним как с текстом. Cмысл в текстовом представлении для форматов которые не предназначены для работы с ними как с текстом ? Файлы реляционных баз, картинки, pdfки (хоть они и текст) odfки (хоть они и текст в архиве) ? Бинарное представление парсится и читается быстрее, а текстовое представление сложных форматов ничего не даст, потому что ничего особо не заскриптуешь из-за сложности этих форматов.

Рациональным путём было бы существование api-модуля(или нескольких модулей) для чтения этих сложных форматов, который можно было бы использовать из скриптов.

>> Специальный случай - это как раз текст ;)

> Так бодаться можно бесконечно.

Нет, тут ка раз всё ясно. Каждый текстовый файл является и бинарным, но не каждый бинарный является текстовым.

>> С /usr/bin/python - очень нравятся. Но это скрипты, а не бинари :)

>Но они же исполняются. Чем не "экзешники"?

Тем, что они исполняются "настоящими" бинарями ("настоящий" бинарь - это то, что не требует трансляции перед исполнением).

>что не требует трансляции перед исполнением

Какой нафиг трансляции ? ELF не парсится ядром ? java bytecode не транслируется jvm'ом ?

>> что не требует трансляции перед исполнением

> Какой нафиг трансляции ?

Трансляция - это процесс перевода с одного языка на другой.

> ELF не парсится ядром ?

Содержимое секций и сегментов - не транслируется.

> java bytecode не транслируется jvm'ом ?

Транслируется. И?

>Транслируется.

Значит байткод в принципе это не трубинарь ? Jpeg это не трубинарь ? Я думал бинарь это всё то что не текст...

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

Не мешает. Но там реализовано именно так.

>> Object.
> Object это не тип данных. Object это Object.

И строка --- это не тип данных. В одном месте ты работаешь с данными как со строкой, а в другом --- как с дотнетным типом.

> Cмысл в текстовом представлении для форматов которые не предназначены для работы с ними как с текстом ? Файлы реляционных баз, картинки, pdfки (хоть они и текст) odfки (хоть они и текст в архиве) ? Бинарное представление парсится и читается быстрее, а текстовое представление сложных форматов ничего не даст, потому что ничего особо не заскриптуешь из-за сложности этих форматов.

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

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

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

> Значит байткод в принципе это не трубинарь ?

Не тру бинарный экзешник.

> Тем, что они исполняются "настоящими" бинарями ("настоящий" бинарь - это то, что не требует трансляции перед исполнением).

А разве /lib/ld-2.9.so совсем никаких преобразований не делает? По твоему определению "настоящие" только статически слинкованные бинари.

> Cмысл в текстовом представлении для форматов которые не предназначены для работы с ними как с текстом ?

Открыл вимом sqlite базу. Смог прочитать часть из её содержимого.
В случае отсутствия специализированной программы для данного mime type это гораздо лучше чем ничего.

> А разве /lib/ld-2.9.so совсем никаких преобразований не делает?

Поэтому я и написал "трансляция". И нет, /lib/ld.so ее не делает.

slowpoke arrived

а где гномосрачЪ? :<

>А вот это уже пробовалось и не пошло.

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

>Сам же видишь, что многое из тобой названного является текстом в каком-либо контейнере.

Ну дык компрессия дешевле дефайнинга бинарного формата для большинства случаев стуктурно-сложных фоматов. И текстовое представление удобно для разработчиков парсера/валидатора. Вот и всё. Авк тебе не очень поможет для таких сложных форматов. xmlpath + dom куда как более полезны для работы с тем же оdt. А они не юникс-вей ибо procedure call. Писать микропарсер для каждой работы с pdf'ой это предел глупости.

>текстовы по сути

всё текстово по сути. даже медиафайлы. Вопрос не в сути, а в рациональном выборе представления на диске. С расцветом гуйни выбор читаемого текста (потому что есть ещё и не читаемый)в качестве представления не рационален не для чего. Даже для исходников (Fortress прекрасно мог иметь и не текстовое предствление) программ.

>самого майкрософта

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