Pull to refresh

Comments 77

Скажу что мне доставило некоторый дискомфорт при использовании Mono — это почти всё, что связано с криптографией. Можно регулярно славливать Exception'ы на коде, который много лет уже успешно работает в MS.Net. «Хит» здесь был
invalid block length at Mono.Security.Cryptography.SymmetricTransform.FinalEncrypt

Выпадал настолько часто, что я его даже запомнил.
Я очень надеюсь, что Xamarin в скором будущем просто скопипастит всю криптографию из MS.NET. Благо, новая лицензия позволяет.
Мы отчасти тоже решали эту проблему копипастой из исходников MS.NET.
Потому что, фактически, эта ошибка происходила в «бутылочном» горлышке, через которое проходят половина методов криптографии, в частности, CryptoStream. И природа ошибки в разных сценариях тоже была разной. Чтобы обходить это, что-то прикрывали «костылями», где-то копипастили исходный код из MS.NET, что-то через некоторое время фиксили разработчики Mono. В итоге всё заработало, но «осадочек остался».
И не думаю, что удастся просто всё взять и всё скопипастить — в криптографии MS.NET много что завязано через WinAPI на нативную «crypt32.dll».
Ну, чем больше получится перетащить из MS.NET в Mono, тем я буду больше радоваться =) Понятно, что на 100% реализация таких больших кусков вряд ли будет совпадать, но жить явно станет проще.
У вас был какой то эксклюзивный доступ к исходникам ms.net? ведь открыли их буквально только что.
Под лицензией «только смотреть, но не трогать» они были доступны уже много лет. Ну и декомпиляторы никто не отменял.
Из криптографии там самое весёлое — SslStream, который совместим со всем чем угодно, но только не с самим собой. Причём патч существует уже года три как минимум, но в апстрим его так и не приняли.
С криптографией у самих MS всё сложно. Основополагающий интерфейс System.Security.Cryptography.ICryptoTransform нельзя использовать даже в родном для MS виде Portable Class Library, не говоря уже про другие платформы. Я так понимаю, что в криптографии у них планируется большой рефакторинг, поэтому временно портирование никуда не идёт.
UFO just landed and posted this here
Когда я говорил людям про Mono 5 лет назад, то на меня очень странно косились. Знаете, наверное они были правы. Как раз вышла версия 2.4 (LTS, кстати говоря, ей до сих пор пользуются). Сейчас я уже плохо понимаю, как под неё что-то можно было писать. А вот текущая версия Mono (3.10) более или менее пригодна для продакшена. Надеюсь, что в ближайшие год-два мы получим Mono, под который можно нормально писать и совсем не страдать.

Запись докладов обязательно будет. Правда, сразу после конференции к ней смогут получить доступ только участники. В открытый доступ запись попадёт спустя какое-то время.
UFO just landed and posted this here
MS сделает некоторые шаги в сторону открытия исходников .NET Framework
Не некоторые шаги, а .NET 4.6 под MIT-лицензией.
Ну, ядро скоро обещают полностью открыть, да. Но тот же WPF открывать вроде бы не собираются, а на Linux/MacOS его хрен портируешь. Да и вообще, в MS.NET очень много вкусных штук, которые на WinAPI завязаны, их не так просто перетащить в Mono. Так что классический .NET-рантайм никуда не исчезнет, будет существовать параллельно с Mono.
а на Linux/MacOS его хрен портируешь
Silverlight вроде является подмножеством WPF, а его порт в природе существует, Moonlight зовётся.
Мне довелось долгое время принимать участие в разработке достаточно большого Silverlight-приложения: Grapholite. SL не взлетел, пришлось портировать под Windows Store и Google Play, но впечатлений осталось очень много. Вот что я могу вам сказать:
1. Сколько бы раз MS не говорили слово «подмножество», никаким подмножеством там и близко не пахнет. Многие вещи сделаны слишком иначе. После краха SL у нас была мысль портировать с SL на WPF, но это очень большая работа.
2. Даже если бы SL и был подмножеством WPF, то он был бы очень грустным подмножеством. Из WPF реально очень много выкинули, чтобы сделать SL. Из-за этого для реализации хоть сколько-нибудь нетривиальных вещей приходится очень сильно извращаться и забивать со всех стороны костыли.
3. С Moonlight-ом было бы всё хорошо, если бы он работал нормально. Да, базовые примеры в нём запускаются, но как только выходишь из песочницы и начинаешь делать что-то нормально, то Moonlight отказывается работать.

Портировать WPF на Mono в нормальной комплектации (чтобы было можно комфортно работать) в теории возможно, но на практике это настолько большая и сложная задача, что вряд ли кто ей будет заниматься.
Помнится, году в 2012-м мы пытались портировать Silverlight-приложение на Moonlight, закопались в проблемах и багах. В итоге нашли такой печальный твит:
twitter.com/migueldeicaza/status/263816476551700481
и официально отказались от поддержки мунлайта.
С тех пор что-то изменилось?
UFO just landed and posted this here
С учетом того, что WPF особо, еще раз повторю: ОСОБО не взлетела

А вот как вы это определили? Тут нужно понимать, что WPF больше всего используется для десктоп-приложений в энтерпрайзе. Очень большой процент этих приложений внешний рынок не видит и никогда не увидит. У WPF есть своя ниша, в которой у него всё хорошо.

что все же есть аналоги WPF\XAML

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

Еще просьба к Вам: когда опубликуют Ваш доклад, ни могли бы скинуть мне ссылку на него?

Лично я к видеозаписи и публикации материалов вообще никакого отношения не имею. Обратитесь лучше к организаторам конференции.
Аналогов хватает, но ни одного такого, которым я бы согласился пользоваться в продакшене для разработки сложного UI.

А как же FXML от JavaFX? Или он тоже плох?
здесь про .NET based разговор идёт
1. Согласен с Borz, мы тут .NET обсуждаем.
2. Ну, быть может я не такой уж и эксперт в FXML, но на мой субъективный взгляд FXML на пару порядков до WPF не дотягивает. Да и с распространённостью у него как-то не очень. Поправьте меня, если я ошибаюсь.
3. Если вы приведёте мне пример действительно сложного GUI от энтерпрайз-приложения на FXML, то буду признателен.
раз уж решили раскрыть таки тему, то на JavaFX не обязательно через FXML писать — можно и напрямую классами фигачить и в этом случае, они «на равных» (не считая багов) с SWT получаются за тем отличием, что для SWT под каждую ОС своя либа подкладывается, а под JavaFX только одна (а в JRE8 так и вовсе не надо — «изкаропки» идёт).
до кучи получаем, хоть и пока несколько сыроватую, возможность сборки под Android/iOS за счёт портов JavaFX (Dalvik | RoboVM).

но багов пока ещё хватает (либо я криво «верстаю») в UI элементах. из «ближайших» — наезд содержимого центральной части BorderLayout на боковую (например west) область при достижении некоего указанного «минимума» (например указал, что center не уже 500px должен быть).
Скорее всего вы «немного» криво верстаете. Так как, к сожалению, в компонентах не всегда адекватно называются свойства и механизм приоритетов не всегда ясен.
Хотя баги тоже есть.
1. Как-то упустил этот момент, извините.
2. Если вы про сравнение WPF и JavaFX, то разумеется, WPF будет иметь больше возможностей. Как минимум потому, что он вышел куда раньше.
Если же про сравнение XAML и FXML, то в FXML можно:
  • собственно, задавать структуру GUI;
  • создавать функции на скриптовых языках;
  • создавать объекты (правильно объявленные, Java же)
  • использовать свои элементы компоновки
  • Использовать Java локализацию для строк сразу же
  • Возможность включать один FXML в другой

Как плюс можно отметить менее странное начало. Вместо пространства имен используется стандартные Java импорты.
В XAML есть еще какие-то дополнительные фичи, которые этим не покрываются? (Когда я учил XAML, там было WPF 3.0).
3. Я бы с радостью, но в энтерпрайз еще повсеместно не вошла даже Java 8 (ибо Java энтерпрайз). Однако, существует достаточно проектов для различных миграций. К примеру, есть Open Dolphin.
Если нужен пример сложного масштабируемого приложение, то можете посмотреть стандартный приложение-пример от Oracle — Ensemble8. Как по мне, весьма сложное GUI.
То что они сейчас открыли уже очень хорошо покрыто тестами чтобы никто не мог сломать реализацию для Windows, а WPF — очень большой по коду и думаю его намного сложнее покрыть тестами. Думаю в этом главная сложность для открытия WPF.
WPF как раз не так сильно завязан на WinAPI (точнее, завязан самый нижний слой — MILCore — и на Direct3D; но там только рендеринг, по сути).

Так что не торопитесь хоронить эту идею. Все может быть.
Ну, в теории-то может. Я очень надеюсь на светлое будущее, в котором будет удобная GUI-система, на которой под все платформы писать можно. Но вот только наступит это светлое будущее не завтра, а разрабатывать нужно уже сегодня. У MS и Xamarin слишком много других важных запланированных задач на несколько лет вперёд, чтобы они ещё и портом WPF занимались. На 5 лет вперёд рынок прогнозировать вообще нереально, но в бизнес-стратегию подобные планы включать точно не стоит. Пока нужно разрабатывать с тем, что есть сейчас, а фоном потихоньку следить за происходящим.
5 лет назад — это еще не так страшно. А у нас первый Linux-релиз был на mono 1.9. У неё тогда было вообще очень много интересных глюков, даже BackgroundWorker фигово работал. Тогда переход на 2.2 казался если не раем, то чем-то в этом духе.
Ох, как тяжко было быть вами. Я вообще плохо понимаю как Mono 1.* можно было для чего-то большого использовать.
метод TypeBuilder.CreateType() не проверял область видимости объявленных интерфейсов. Т. е. код
Mono вообще много чего не проверяет. Я как-то случайно натравил ldfld (вместо ldsfld) на статическое поле, так Mono вытащил значение instance-поля с тем же номером, в итоге в переменной типа List оказалась строка. Я тогда ещё долго смотрел на это счастье в отладчике и пытался понять, как же так.
Ох, полностью с вами согласен. Если IL-код хоть немного похож на что-то вменяемое, то Mono его жрёт и спокойно исполняет. Иногда даже получается ожидаемый результат. В это же время MS.NET на любой самый мелкий косяк начинает закидывать экзотическими исключениями, по которыми документация практически отсутствует.
Разрабатывал когда-то сервачок на .NET/Mono, крутился в продакшене как на винде, так и на лине, особого геморроя с Mono не было… Причем работал и дебажил в студии под виндой, а после уже заводил на линь, практически без изменений, и все просто работало… :) Правда, пока не подключился дополнительный "разработчик", но это уже другая история)))
Если бы ещё не накладные расходы, которые вылезают при использовании XSP/mod_mono, было бы вообще замечательно. Для примера см. бенчмарк: NancyFx с самописным хостом на базе libevent обходит NancyFx хостящийся на XSP в 21 раз.
Неужели все настолько плохо под линуксом и никак не сравнять скорость работы с windows?
В следующем раунде мой evhttp-sharp отработал с 91,557 запросов в секунду. Конкурировать с виндовым http.sys (он всё ж таки в ядре ОС работает) на базе деревянного HTTP-сервера из состава libevent дальше сложно, надо брать proxygen или что-то типа него.
Это уже приемлемо, найти бы еще статью на хабре, как это все правильно приготовить ;)
Для ASP.NET WebPages/MVC — никак, там только через Hyperfastcgi. Для всего остального можно воспользоваться OWIN-хостом из состава либы.
Ну, «простой» код действительно запускается нормально. Проблемы чаще всего начинаются в тот момент, когда вы собираетесь делать что-нибудь «эдакое».
У нас в GitExtensions основные проблемы есть с GUI, WinForms под Mono работает ужасно (что и следовало ожидать по названию). Может быть переписывание на Gtk# и решило бы проблемы но очень не хотелось бы потерять редактор форм, тем более я думаю в нем багов тоже хватает.
В MonoDevelop(Xamarin Studio) есть редактор форм для GTK#, кроме того есть отдельный Glade
Спасибо. А у кого-нибудь есть опыт использования Gtk# в продакшене? Насколько он стабильный и удобный в использование?
Я использовал. Не сказать, чтоб в больших проектах, но опыт есть. Gtk# биндится к старой версии Gtk2. И под Win и Mac выглядит это довольно паршиво. В целом со стабильностью проблем не замечал.

Сейчас смотрю в сторону Xwt, но пока только приглядываюсь
Делали на Gtk# клиент для Kebrum. Стабилен как совок времён хрущёвской оттепели. По удобству примерно так же.
Я изначально имел ввиду серверную версию. Увы, вменяемого GUI под все платформы нет.
На мой взгляд, QML — это самая вменяемая разметка для GUI после XAML-семейства. Но, увы, QML под .NET пока не изобрели, а на плюсах после шарпика без особой необходимости писать не хочется.
О, да, как же сложен C++ даже в QT после C# :(
Ну, я бы не сказал, что он прям сложен — при должном усердии вполне можно со всем разобраться. Другой вопрос, что в C# платформа об очень многих вещах думает за меня, а я могу сосредоточиться на высокоуровневых штуках. А в С++ приходится быть намного более внимательным и тратить время на более низкие уровни абстракции.
При переносе программы от MS.NET 2.0 на более высокую версию столкнулся с тем что поменялась реализация одной из коллекций — условно говоря, там где был массив стал итератор или как-то так — не помню уже точно, давно было. Суть в том, что в тексте стояли foreach, а это синтаксический сахар с кучей условий — типа если есть итератор то используем его итп. Так вот, если не перекомпилировать то с новым дотнетом выпадала ошибка на отсутствие метода, но перекомпиляция того же кода давала рабочий код. Думаю что при переходе на Mono или между версиями mono возможны подобные эффекты тоже.
В Моно 2.2 мой сервер работал, но страшно медленно. Разобрал, изучил, нашел, что Array.BinarySearch выполняется в 20 раз медленее, чем в .Net на больших массивах и задал себе вопрос: что это вообще за фигня — поиск по массиву в критичной по времени серверной части? Переделал на хеш таблицы и стало все замечательно на обеих платформах (± мелочи). С тех пор код пишу сразу с прицелом и на Mono, с Path.DirectorySeparator и с профайлингом mprof.
Надо будет проверить. Реализация поиска с тех времен не поменялась (Mono-2.2-BinarySearch, Mono-3.10-BinarySearch). Microsoft явно сделали лучше (MS.NET-4.5.2-BinarySearch). Для SZArray есть нативная имплементация (MS.NET-4.5.2-TrySZBinarySearch), так что понятно почему она работает быстрее. Вопрос в том — насколько?
Не надо проверять, надо отправить пул-реквест с переносом кода (либо референс на весь файл, либо partial-class, либо просто копипаст с переформатированием) следуя рекомендациям. Код array.cs под MIT лежит тут.
Портировать надо вот эту штуку:
[MethodImplAttribute(MethodImplOptions.InternalCall)]
private static extern bool TrySZBinarySearch(Array sourceArray, int sourceIndex, int count, Object value, out int retVal);

Нативные исходники где-нибудь доступны?
Моно пробовал давно, когда правил балом еще .Net 1.1, поэтому все истории про MS.NET :)

Первая про сортировку массивов, был у нас код который сортировал массивы из пары сотен тысяч элементов, предвкушая возмущения, скажу что сортировка для UI. И так все отработано, сортировка работает достаточно быстро для того, что бы не быть заметной пользователям. Но в какой-то момент времени получаем тикет, долго грузится система, начинаем искать. Находим, дело в том, что MS изменила алгоритм сортировки с целью его оптимизации в .Net 3.5 и алгоритм стал нестабильным! По не понятным причинам, он мог то работать с прежней скоростью, то проваливаться в производительности в сотни и тысячи раз! Полечили своей реализацией квиксерча, после выхода .Net 3.5.1 все было исправлено, вернулись на родную реализацию.

Вторая про работу в много экранном режиме под виртуальными машинами, всей подноготной не помню, но у нас клиенты работали в облаке через удаленный доступ предоставленный сервисами Citrix, все бы хорошо но! У некоторых клиентов все элементы меню, всплывающих окон и подобных элементов UI были просто перечеркнуты красным крестом, такое можно увидеть при падении UI потока при отрисовке содержимого контрола. Расследование показало, что .Net в таком режиме работы не может определить основной монитор, если он не установлен в системе как левый нижний! А у .Net внутри много кода который оперирует аксиомой, что основной монитор всегда не null, результат падение всего кода внутри .Net использующего информацию о основном мониторе.

Исправить и то и то, стало возможным только из за желания разобраться, что там не так :)
А что используется в вашем PassportVision, упомянутом в статье, для GUI?
Ведь WPF под Mono не работает. WinForms?
Тогда мне не совсем понятно, как именно они заставили его работать под Mono :O
Под Mono мы портировали часть без GUI. Есть много заказчиков, которые хотят запускать PassportVision под Linux-сервером, и ни одного, кто хотел бы запускать PassportVision под Linux-клиентом.
Сценарий у многих такой, что люди хотят делать самую важную часть работы (распознавание документа) на сервере. Далее либо используется наша верификационная форма на Windows-клиенте (проверяются полученные с сервера данные), либо используется собственный интерфейс заказчика (многие хотят именно встроить PassportVision в свою систему без появления лишних форм).
Основная претензия к mono приходит из-за процесса установки и запуска приложений. Миллионы каких-то «сборок», которые зачем-то компилируются (как будто это gentoo, а не debian), первый старт любого приложения под mono сопровождается таким количеством IO, что за это можно загрузить пару компьютеров с начала и до запука FF.

Памяти приложение на mono отъедает так, как будто у компьютера этой памяти сотни мегабайт свободной. Заметим, отъедает «под собственные нужды» без особого смысла. На фоне нативных приложений линукса, у которых основной runtime — это libc, mono выглядит неповоротливым монстром.
Я считаю, что вы излишне драматизируете. Да, проблемы есть, но в последних версиях они не настолько критичны. С установкой и первым стартом всё действительно не так весело, а вот с расходом памяти нужно смотреть по конкретной программе. «Пустая» программа у меня кушает ~1.5MB, так что рантайм просто так сам по себе не особо память расходует. Проблемы идут из-за хреново сделанной сборки мусора и аллокации памяти под объекты. Если выставлен boehm, то вообще вешаться можно. С sgen ситуация заметно улучшилась, но там свои приколы с выделением памяти есть, с которыми всё очень сложно. Я крайне надеюсь, что после открытия MS-рантайма Мигель первым делом побежит воровать GC. А пока что остаётся только оптимизировать под Mono, увы.
Я не драматизирую, я описываю позицию пользователя. «Я хочу эту программу» — «поставь ЭТОТ РАНТАЙМ» — «ЗАЧЕМ?» — «Т А К Н А Д О !!111».

Примерно как если бы в кафешке «я хочу вот это пироженное» — «ок, но вам сначало надо съесть пригоршню вот этих камешков. Они безвредны и позволяют нам обеспечить общий техпроцесс в этом кафе и вот в той забегаловке».

С точки зрения пользователя весь .net и mono — это чистой воды блотваря, которую втюхивают вместе с полезным приложением. Одного класса с всякими тулбарами. Они нужны разработчику, но нафиг не сдались пользователю.
А тут встаёт вопрос о стоимости и времени разработки.
Например, я могу написать программу на C# за год. Она будет работать не всегда быстро, жрать не так мало памяти, но уже через год пользователь сможет ей пользоваться.
Эту же программу я могу написать на С++, для примера, за 2 года. Она будет работать быстрее, жрать меньше памяти, но будет у пользователя только через 2 года.
А могу написать на ASM. Причём, сделать отдельную версию под каждую архитектуру и под каждую операционную систему. К примеру, сделаю я это за 15 лет. Только вот через это время программа уже никому нужна не будет.

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

Резюмирую. Если вы хотите маленькое пирожное за 50 рублей, то вполне можно найти кафе без камешков. А если вы хотите 10-ярусный торт со стриптизёршей внутри и завтра, то придётся смириться с тем, что кафе нужно выбирать специфическое, а вместо 200 грамм тортик будет весить 200кг.
Ну так я в самом первом абзаце и написал:
Вышеприведённая картинка утратила свою былую актуальность
«Чукча не читатель, чукча писатель.»
Сорри не заметил =)
Вышеприведённая картинка утратила свою былую актуальность, ведь исходники теперь будут под MIT
Третье предложение в тексте. опоздал :)
Не знаю на сколько хорошо Mono работает на десктопах но например достаточно простое приложение под Android работающее с помощью Mono (HighLoad++ например, которым недавно так сильно хвастались разработчики на последней конференции от Yandex) работает неудовлетворительно медленно.
Ну, опять-таки, нужно смотреть что конкретно работает медленно. «Простое» — это не описание. Проседание производительности может вызвать «простой» код на несколько строк. Быть может, много объектов создаётся, и GC начинает грустить. Может быть рендерится что-то хитрое. Скорее всего проблемы со скоростью упираются в два-три важных момента, по которым нужно проводить оптимизацию.
Насчёт багов в .Net и mono.
DateTime.Now.ToString("m");
В Mono возвращал «Ноябрь 1»,
Windows phone 7 «1 ноябрь»
Windows phone 8 «01 ноябрь»

Писал в моно баг — исправили, теперь как в .NET…
Отлично, просто отлично. Добавляю себе в коллекцию.
А у вас не осталось где-нибудь номера бага?
Нет, не помню. Сам репортил в bugzilla.xamarin.com — не нашел. Ещё они имеют нехорошую привычку скрывать некоторые багрепорты…
У них ещё поиск дурацкий — очень сложно что-то найти.
Нашел . Там даже интереснее, Xamarin возвращает одно, а моно другое :)
Есть здоровенный проект под ms.net с >1000 тестов под MSTest. Как выполнить их под Mono? Портировать на NUnit или можно все таки запустить mstest под mono?
Ну, быть может и можно как-то запустить, но если вы собираетесь работать под Mono, то я бы всё-равно посоветовал переписать под NUnit. Думаю, это не должно быть такой уж большой задачей.
Sign up to leave a comment.