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

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

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

N>>А всего-то надо было при формулировке стандарта .NET подумать не только про виндовую среду... впрочем, видимо, это было не в интересах MS.
S>А можно пример мест, в которых .net явно заточен под win?

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

Автор: netch80
Дата: 05.02.12

хотя бы. По описанному мы отказались от любых попыток завести что-то .NET основанное под Unix для наших задач.
Судя по тому, что сейчас видно, ситуация не лучше — использование .NET под Unix не вышло за пределы одной локальной ниши "графические приблуды под Unity".

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

NB>видимо, MS пох. на то, есть ли .NET за пределами виндовса.

Ну а я о чём. А в результате Ткачёву, которого "тянет блевать от линукса"

Автор: IT
Дата: 31.01.14

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

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

S>>А можно пример мест, в которых .net явно заточен под win?
N>Во-первых, следи за формулировками и не приписывай лишнего. Разница между "явно заточен под Windows" и "подумать не только про Windows" принципиальная, а в данном случае ещё и существенная.
Знаешь, если понимать твоё утверждение как "в .net не должно быть вещей, удобных для программирования под win", то всё становится ещё более странным. Напомню, mono существовал с 2005 года, но коммерческого интереса к нему не было вплоть до появления xamarin и возможности разработки под ios/android. Нет коммерческого интереса => нет целевой аудитории => нет необходимости что-либо делать. Вполне логично, что основной интерес уделялся именно возможностям разработки под win.


N>Во-вторых, вот такое

Автор: netch80
Дата: 05.02.12

хотя бы. По описанному мы отказались от любых попыток завести что-то .NET основанное под Unix для наших задач.
1. По ссылке не совсем .Net, а IronPython, который в официальный список поддерживаемых языков не входит.
2. Претензии по ссылке:
* Нам не подходит типовая перегрузка "OpenFile". File.Open — это просто хелпер, обёртка вокруг "new FileStream(...)". Что мешало сделать свой?
* Грабли с интеропом. Вопрос: вы там точно использовали FileStream.SafeHandle.DangerousGetHandle()? Если да — очевидно баг в mono, в win всё отдаётся корректно.
И это всё?

N>использование .NET под Unix не вышло за пределы одной локальной ниши "графические приблуды под Unity".
Так причина не в технических ограничениях, их немного; реальный софт это подтверждает. Проблема не столько в самом mono, сколько в отсутствии перспектив в массовом портировании managed-софта под lin.

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

S>А можно пример мест, в которых .net явно заточен под win?
Проще будет тебе привести хотя бы одно место, где он не заточен.

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

S>>>А можно пример мест, в которых .net явно заточен под win?
N>>Во-первых, следи за формулировками и не приписывай лишнего. Разница между "явно заточен под Windows" и "подумать не только про Windows" принципиальная, а в данном случае ещё и существенная.
S>Знаешь, если понимать твоё утверждение как "в .net не должно быть вещей, удобных для программирования под win",

А с чего бы его именно так понимать?
В .NET, как в любой подобной среде, есть 1) основа виртуальной машины (байткод и её исполнение), 2) библиотеки, не связанные с ОС или минимально с ней связанные (например, regexps, mutex/CV/etc., очереди, массивы и т.д.), 3) библиотеки, связанные с ОС (например, то же понятие файла уже есть концептуальное ограничение). Для (1) и (2) нет специфики, и с ними всё в порядке. Но в (3) введены _для всех_ особенности работы, которые полезны или вообще имеют смысл только для Windows.
Сравни, например, с Си. Кроме стандартной библиотеки, которая в основном досталась в наследство, ничего из новых добавлений не специфично для Unix, Windows, zOS или любой другой ОС.

S> то всё становится ещё более странным. Напомню, mono существовал с 2005 года,

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

S> но коммерческого интереса к нему не было вплоть до появления xamarin

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

S>1. По ссылке не совсем .Net, а IronPython, который в официальный список поддерживаемых языков не входит.
S>2. Претензии по ссылке:
S>* Нам не подходит типовая перегрузка "OpenFile". File.Open — это просто хелпер, обёртка вокруг "new FileStream(...)". Что мешало сделать свой?

Тем, что это значит брать на себя сопровождение чужого кода (IronPython), тщательно отслеживать его разработку, при мерже ловить все подозрительные места и зачищать их, делать своё пакетирование... дорого, марудно и ненадёжно.
И всё это вместо того, чтобы пусть даже явно вызвать один раз при старте процесса что-то вроде SetRuntimeStyle(STYLE_UNIX) и удовлетвориться результатом во всех смыслах.
Альтернатива, ещё более дурная — делать персональную сборку самого Mono для этого.

S>* Грабли с интеропом. Вопрос: вы там точно использовали FileStream.SafeHandle.DangerousGetHandle()? Если да — очевидно баг в mono, в win всё отдаётся корректно.

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

S>И это всё?

А что, мало?

N>>использование .NET под Unix не вышло за пределы одной локальной ниши "графические приблуды под Unity".
S>Так причина не в технических ограничениях, их немного; реальный софт это подтверждает. Проблема не столько в самом mono, сколько в отсутствии перспектив в массовом портировании managed-софта под lin.

Тогда почему полно этих перспектив для написания и портирования managed-софта на Java под Linux?
У меня единственное объяснение — потому что Java создавалась под работу на SysV, а Linux заменил собой SysV для >99% потребителей. И Java рантайм, соответственно, не ставит грабли для Unix.

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

N>3) библиотеки, связанные с ОС (например, то же понятие файла уже есть концептуальное ограничение). Для (1) и (2) нет специфики, и с ними всё в порядке. Но в (3) введены _для всех_ особенности работы, которые полезны или вообще имеют смысл только для Windows.
Ну так что мешает lin-сообществу добавить свои хелперы и распространять их через nuget, как это делает МС с большинством новых дополнений? Не, серьёзно: что в IO/WCF/ASP.Net mvc/Ado.NET принципиально завязано на Win?

N>Сравни, например, с Си. Кроме стандартной библиотеки, которая в основном досталась в наследство, ничего из новых добавлений не специфично для Unix, Windows, zOS или любой другой ОС.
В стандарт дотнета входит только ограниченный набор BCL и он в принципе вполне кроссплатформенен. Наличие в mono остальных библиотек и их портируемость — это уже вопрос доброй воли команд MS/mono. Принципиальных отличий от си я тут не вижу.

S>> то всё становится ещё более странным. Напомню, mono существовал с 2005 года,
N>Начал разрабатываться около 2001, согласно википедии. Первые анонсы я помню как раз в те годы. 2004 это уже 1.0, законченная.
Ага, с датами напутал. Имел в виду именно первые более-менее стабильные релизы

N>Суровая коммерческость интереса тут не важна. Есть интересный движок и желание что-то писать под него.
Нет коммерческого интереса — получаем поддержку силами сообщества и закономерный результат в виде "кому нафиг нужен дотнет под lin?". Есть поддержка — получаем xamarin или unity, который покупают, несмотря на ценники вида "килобакс в год для каждого разработчика".

S>>* Нам не подходит типовая перегрузка "OpenFile". File.Open — это просто хелпер, обёртка вокруг "new FileStream(...)". Что мешало сделать свой?
N>Тем, что это значит брать на себя сопровождение чужого кода (IronPython), тщательно отслеживать его разработку, при мерже ловить все подозрительные места и зачищать их, делать своё пакетирование... дорого, марудно и ненадёжно.
А, понял проблему. Тут два варианта: если менять поведение OpenFile в зависимости от платформы — получим падающий при запуске на другой платформе софт. Не менять — получим тормоза и блокировки, коротые в принципе решаются написанием хелпера + заменой кода по всему солюшну.

Ну и это точно проблема самого питона, дотнетовский FileStream использует нативные средства для задания FileShare.None.

S>>* Грабли с интеропом. Вопрос: вы там точно использовали FileStream.SafeHandle.DangerousGetHandle()? Если да — очевидно баг в mono, в win всё отдаётся корректно.
N>_Мы_ _точно_ использовали библиотечные средства Питона, у которых такого вызова нет.
Ага, т.е. обе проблемы сводятся к
1. Мы использовали опенсорсный IronPyton, который абсолютно не портируется под lin
2. Виноват в этом MS так как он не озаботился "при формулировке стандарта .NET подумать не только про виндовую среду"


N>Тогда почему полно этих перспектив для написания и портирования managed-софта на Java под Linux?
N>У меня единственное объяснение — потому что Java создавалась под работу на SysV, а Linux заменил собой SysV для >99% потребителей. И Java рантайм, соответственно, не ставит грабли для Unix.
Абсолютно точно. В тоже время количество явы под win намекает, что проблема работает в обе стороны

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

N>>3) библиотеки, связанные с ОС (например, то же понятие файла уже есть концептуальное ограничение). Для (1) и (2) нет специфики, и с ними всё в порядке. Но в (3) введены _для всех_ особенности работы, которые полезны или вообще имеют смысл только для Windows.
S>Ну так что мешает lin-сообществу добавить свои хелперы и распространять их через nuget, как это делает МС с большинством новых дополнений? Не, серьёзно: что в IO/WCF/ASP.Net mvc/Ado.NET принципиально завязано на Win?

Не знаю. Меня, кажется, ничего из названного не интересует — ни ASP[.NET], ни ADO, ни MVC... а вот проблемы базы, которая требует переделки начиная с ECMA стандарта — оказались существенны.

N>>Суровая коммерческость интереса тут не важна. Есть интересный движок и желание что-то писать под него.
S>>>* Нам не подходит типовая перегрузка "OpenFile". File.Open — это просто хелпер, обёртка вокруг "new FileStream(...)". Что мешало сделать свой?
N>>Тем, что это значит брать на себя сопровождение чужого кода (IronPython), тщательно отслеживать его разработку, при мерже ловить все подозрительные места и зачищать их, делать своё пакетирование... дорого, марудно и ненадёжно.
S>А, понял проблему. Тут два варианта: если менять поведение OpenFile в зависимости от платформы — получим падающий при запуске на другой платформе софт. Не менять — получим тормоза и блокировки, коротые в принципе решаются написанием хелпера + заменой кода по всему солюшну.
S>Ну и это точно проблема самого питона, дотнетовский FileStream использует нативные средства для задания FileShare.None.

Ну не питона в целом, а IronPython, но таки да.

S>>>* Грабли с интеропом. Вопрос: вы там точно использовали FileStream.SafeHandle.DangerousGetHandle()? Если да — очевидно баг в mono, в win всё отдаётся корректно.
N>>_Мы_ _точно_ использовали библиотечные средства Питона, у которых такого вызова нет.
S>Ага, т.е. обе проблемы сводятся к
S>1. Мы использовали опенсорсный IronPyton, который абсолютно не портируется под lin
S>2. Виноват в этом MS так как он не озаботился "при формулировке стандарта .NET подумать не только про виндовую среду"
S>

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

N>>Тогда почему полно этих перспектив для написания и портирования managed-софта на Java под Linux?
N>>У меня единственное объяснение — потому что Java создавалась под работу на SysV, а Linux заменил собой SysV для >99% потребителей. И Java рантайм, соответственно, не ставит грабли для Unix.
S>Абсолютно точно. В тоже время количество явы под win намекает, что проблема работает в обе стороны

Угу. И при выборе — Java или .NET — для меня выбор очевиден. Несмотря на опережение C# + .NET в некоторых областях.

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

N>Угу. И при выборе — Java или .NET — для меня выбор очевиден. Несмотря на опережение C# + .NET в некоторых областях.

Это в каких же областях дотнет опережает??

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

S>>А можно пример мест, в которых .net явно заточен под win?
V>Проще будет тебе привести хотя бы одно место, где он не заточен.
Открываем MSDN и читаем, пропуская платформенно-зависимые штуки типа winforms и EnterpriseServices

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

N>Не знаю. Меня, кажется, ничего из названного не интересует — ни ASP[.NET], ни ADO, ни MVC... а вот проблемы базы, которая требует переделки начиная с ECMA стандарта — оказались существенны.
Ну а нафиг тогда .net? Что там остаётся такого, что нельзя заменить простым питоном или явой?

N>Ну не питона в целом, а IronPython, но таки да.
N>Вот ты не смог, конечно, удержаться и не написать, кто "виноват". Я ни слова говорил про _вину_. Я говорил про источник проблемы. Разницу видишь?
Не, пойнт не в том. Аналогия (сильно утрирую): мы используем библиотеку на си, которая не портируется под lin, но виноват в этом язык, т.к. Страуструп при разработке не озаботился подумать про non-unix-системы.

Портируемость оговорена явно для подчасти BCL (при соблюдении языком CLS конечно). Всё остальное — на совести разработчиков конкретного языка/библиотеки. Если они закладывают поведение отличное от дефолтного (и тем более не дают его поменять), то MS тут ничем помочь не может.

N>Угу. И при выборе — Java или .NET — для меня выбор очевиден. Несмотря на опережение C# + .NET в некоторых областях.
Ну так области использования у них пересекаются редко, так уж сложилось. Если ничего из возможностей .net не нужно (или не хватает того что в .net нет) — зачем кушать кактус?

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

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

S>>А можно пример мест, в которых .net явно заточен под win?
V>Проще будет тебе привести хотя бы одно место, где он не заточен.

Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?

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

N>>Не знаю. Меня, кажется, ничего из названного не интересует — ни ASP[.NET], ни ADO, ни MVC... а вот проблемы базы, которая требует переделки начиная с ECMA стандарта — оказались существенны.
S>Ну а нафиг тогда .net? Что там остаётся такого, что нельзя заменить простым питоном или явой?

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

N>>Угу. И при выборе — Java или .NET — для меня выбор очевиден. Несмотря на опережение C# + .NET в некоторых областях.
S>Ну так области использования у них пересекаются редко, так уж сложилось. Если ничего из возможностей .net не нужно (или не хватает того что в .net нет) — зачем кушать кактус?

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

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

C>Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?

Дык тру-юникс-строчка должна жеж быть UTF-8 и никак иначе. Иначе неправославненько и вообще богомерзко жеж?..

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

N>Идея была опробовать для питона другой движок. Предполагалось, будет заметно шустрее.
Енто все поняли, но выяснилось, что те, кто айронпитон делали, сделали как раз так, как тебе нравится. Типа поменяли все умолчания на такие, которые они естественными считают, а на совместимость тупо забили. Да. так что этот ваш айронпитон -- та ещё какашка. Странно, что ты на неё посмотрел и теперь говоришь, что мновоцы не молодцы, что так же не стали делать. Это то, чего лияно я не понял в твоей позиции.
Но ты самое интересное не осветил, шустрее-то получилось?..

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

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

A>Многие посетители КЫВТ-а регулярно пишут вещи, которые показывают полное непонимание мотивации компании, стоящей за теми или иными решениями.
A>Мне кажется, настала пора приоткрыть этим людям глаза на происходящее.

A>Итак, зачем Майкрософту рубить сук

Дальше можно не продолжать.

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

E>Дык тру-юникс-строчка должна жеж быть UTF-8 и никак иначе. Иначе неправославненько и вообще богомерзко жеж?..

А какая она в дотнете по-твоему?

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

K>А какая она в дотнете по-твоему?
Дык Char жеж, AKA UTF-16...

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

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

C>>Ну давай к примеру возьмем класс System.String, покажешь, в каком месте он заточен под винду?

E>Дык тру-юникс-строчка должна жеж быть UTF-8 и никак иначе. Иначе неправославненько и вообще богомерзко жеж?..

Ну ок, с натяжкой согласиться можно . Что в общем то не отменяет того факта, что это исключительно вопрос внутренней реализации программы, написанной на дотнете, и все манипуляции с внешними источниками, ака файлами, один шут по умолчанию производятся в UTF-8, см. дефолтные параметры в StreamWriter например.

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

NB>ок. и что мешает тебе пропихнуть моно, а потом под шумок поменять серваки?

Моно пока всерьёз никто не воспринимает. Хотя это, конечно, тоже больше отмазка, чем реальность. Да и не думаю, что с Моно всё так хорошо. Например, не уверен, что для Моно существует ADO.NET драйвер для DB2. Он для Windows наполовину нативный, а уже для Моно им вряд ли кто-то озаботился.