Pull to refresh

Comments 62

Еще положение вещей в дотнете сейчас хорошо иллюстрирует список steering group в .NET foundation:


Мне все интересно, зачем это гуглу (и Самсунгу). С остальными сейчас понятно.
У гугла есть облачный сервис в котором это все можно запускать. Возможно, есть еще какой-то интерес. Samsung будет использовать в Tizen
Samsung, too, is deepening its commitment to .NET by launching support for it on its Tizen platform. As Samsung’s Hong-Seok Kim told me, Samsung was looking for a framework in addition to the web framework and C API that Tizen developers currently use to write their applications.

https://techcrunch.com/2016/11/16/google-signs-on-to-the-net-foundation-and-samsung-brings-net-support-to-tizen/
А какой именно сервис?  UPD. Аа, понял — облако от гугла, честно говоря, впервые вижу.
Про Tizen - интересно. Ксамарин портируют?

Нет, неткор. Очень активно пуллреквестят в поддержку линукса/arm на неткоре.

ну, с одним неткором мбильное приложение не напишешь :)
Поясните, пожалуйста. мысль для не улавливающих с лёта.

Это компании, которые включились в разработку .NET Core и смежных проектов.

Спасибо, это я понял. Я не понял как именно этот список иллюстрирует положение вещей. Всё хорошо? Или всё плохо?

Embrace Extend & Extinguish. Microsoft проявляет исключительное дружелюбие и открытость в областях, где она в чём-то отстаёт. А в областях, где она лидирует, мы можем наблюдать совершенно противоположное поведение: Microsoft защищает свою экосистему закрытыми стандартами с патентными органичениями на стороннюю реализацию.

А есть какие-то факты по ЕЕЕ кроме тех бородатых по ссылке?

Сейчас Касперский недоволен политикой внедрения и параллельной работой их(Майкрософта) собственного антивируса

А причем тут EEE? МС хочет безопасность из коробки. Это угрожает бизнесу Касперского, построенному на дырявости старых версий Windows… Или там что-то еще?
Не буду обсуждать его посты, так как в чем-то есть здравое зерно, а в чем то нет. Скажу лишь, что желание вендора сделать свой продукт надежным — похвально. Но всем не угодить.

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

Есть.


Формат OOXML(*.docx и т. д.), спешно созданный в противовес открытому OpenDocument(появившийся из OpenOffice.org XML) от OASIS. Переусложнённый, защищён патентами, которые могут вызвать юридические проблемы у реализующих его программ.


Проблемы с ключами UEFI SecureBoot на некоторых платформах(вроде бы в итоге решили).


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


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

А причем тут EEE? :) Обычный бизнес подход.
1. Вроде ECMA-376, ISO/IEC 29500. Какие проблемы?
2. А причем тут МС? :) Ленивый вендор не хочет заморачиваться с ключами для *Nix. MS как раз вроде даже подсобил с получением ключиков.
3. И что тут такого? Где тут EEE? Тупой обычный бизнес: покупай у меня, а не у Васи — будет тебе скидка.

Пример таких новых протоколов? Что-то не заметил патентов MS на поддержку Brotli в Edge, например.

Да, ECMA-376, ISO/IEC 29500, они в итоге протолкнули своё защищённое патентами со всех сторон поделие как открытый стандарт.


Про ситуацию с ключами точно не скажу, не отслеживал.


"Не выпускай без предустановленной ОС вообще, а то ценами задавим" — да, обычный бизнес, но методы недобросовестные.


Странно было бы видеть патенты на Brotli, который не в MS разрабатывался.

Office Open XML
Microsoft has added the format to their Open Specification Promise[27] in which

Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification […]

Где не добросовестные? Хочешь скидку — выполни условие. Если нет — покупай по общим правилам.
Ну Dell продает вроде и ничего с ним не случилось. Кто хотел — выпускал все подряд.

«Но насколько я понимаю, они по-прежнему любят реализовывать форматы и протоколы несколько отличающиеся от существующих стандартов, и огораживать всё это патентами.» Хотелось бы примеров, а то опять теории заговоров какие-то.

Им это нафиг не надо. Основные бабки уже в облаке. Поэтому и SQLServer на *Nix поехал, они стали членом Linux Foundation, а Canonical им Ubuntu в Винде пилит.
> Microsoft irrevocably promises not to assert…
Не знал. Им приходится прогибаться под антимонопольное законодательство, это хорошо.

> SQLServer на *Nix поехал, они стали членом Linux Foundation
Их основной бизнес — продажа ОС и некоторого серверного софта. В облаке, в железе — не суть дело важно. Open-Source решения — их прямой конкурент, хоть бесплатные, хоть с поддержкой от RedHat/Canonical/Percona/… Так что в добрые мотивы верится слабо, они вынуждены интегрироваться в систему OpenSource софта, потому что молча её игнорировать уже не получается. Ну и в порядочность фирмы, которая занималась вещами вроде EE&E, верится слабо. Те же самые люди, которые это делали, сидят там на тех же или более высоких должностях(минус небольшой процент ушедших на пенсию).
С них сняли антимонопольный надзор. Просто хватило ума не идти по пути Оракла.

Их основной бизнес — облако, сервисы и уже потом серваки. Прошло уже 15 лет, а бубнеж про ЕЕЕ все никак не успокоится. Те люди которые это делали уже играют в анонимного санту или занимаются американским футболом.
> Хотелось бы примеров, а то опять теории заговоров какие-то.
Я уже долгое время практически не имею дела с экосистемой Windows, что там сейчас происходит, не расскажу. Но раньше у них и керберос был со своими дополнениями, и IE со своей своеобразной интерпретацией веб-стандартов, и всё остальное в том же духе. Кстати, IE они в приличный вид стали приводить, только когда проиграли рынок браузеров, и были _вынуждены_ это сделать.
Ну если не имеете, то перед тем, как повторять старые мантры, неплохо было бы освежить знания :) Где-то догоняют, где-то обгоняют, где-то обделываются. Как и любая технологическая компания. Сейчас менеджмент включил мозг, а облако позволило уйти от дикой завязки на ОС.
Хотел уже закончить дискуссию, но тут на реддите пробежала интересная ссылка: http://techrights.org/2016/12/06/microsoft-bundling-or-patent-lawsuit/

Белый и пушистый Microsoft, перешедший на сторону добра и вкладывающийся в OpenSource, входит в состав крупного патентного агрегатора и патентного троля RPX. Кроме того, бывшим CTO Microsoft Nathan Myhrvold при поддержке Била Гейтса был создан патентный тролль Intellectual Ventures. Эти конторы получают деньги с производителей linux-based устройств(сейчас в основном Android), шантажируя их возможными судебными исками.

То есть, как я и предполагал, люди, которые раньше зарабатывали деньги, нанося вред развитию технологий подлыми и нечестными способами(хотя и законными), и сейчас занимаются тем же самым. Просто в некоторых областях OpenSource решения их переиграли, и они вынужденны примазываться.
А разве так поступает не любая корпорация?

Хотя не, есть исключение — Apple, они даже в областях, в которых чувствуют себя неуверенно ведут себя агрессивно ;) и добиваются успеха надо признать.

Есть агрессивное поведение, а есть нечестные методы борьбы, наносящие в итоге ущерб развитию технологий в целом. Безусловно, этим занимается не только Microsoft.

Косвенно об этом свидетельствует недавний выпуск превью Visual Studio для Mac, который компания сделала в ноябре этого года.

Это MonoDevelop (aka Xamarin Studio) с переклееным логотипом, если что.

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

Буквально недавно хотел сваять простенький REST сервер и обнаружил, что в net core нет реализации простейшенго HttpListener. Предполагаю, что если взять какой-то большой проект, то с большой долей вероятности всплывёт ещё куча ошибок. Очень жаль.

Asp.net core не смотрели? :)


А HttpListener нету потому что он использовал HTTP.SYS, которого в линуксе тоже "почему-то" нету.

Конечно смотрел, мне просто кажется не правильным тянуть архитектуру, которую я не очень хочу поддерживать в собственный проект. Мне нужен базовый listener, как был в .net и не более того. Ну и вообще странно, что наследник (понятно, что сейчас просто порт, но всё возможно в будущем) .net не совместим с ним обратно, вам не кажется?
Ничего странного. Breaking changes бывают у всех.
.NET Core не является прямым наследником .NET Framework. Скорее .NET Standart таковым является.
.Net Standard по факту и есть .Net Core, они даже в одной вкладке в студии существуют. Разница только в том, что кор — запускаемое приложение, а стандарт — библиотека. Ну и еще в деталях, типа fallback'ов на взрослый фреймворк и всего такого.
.Net Standart — описание подмножества API. Соответственно реальный Фреймворк, будь то .net framework, .net core, Xamarin поддерживает определенную версию стандарта. Это нужно что бы можно было написать библиотеку, которая компилируется с любым Фреймворком, поддерживающим данную версию стандарта.

imageimageimage
Я не думаю, что корректно говорить о «наследнике .net framework», потому что стандарт скорее наследник PCL, нежели чего-то еще. А если посмотреть шире, то феномен вообще для дотнета беспрецедентный, спек на АПИ раньше не было.
WebListener(http.sys) за него или Kestrel(x-plat). У нас уже на проде работает.
А еще есть WCF (который хоть и использует тот же WebListener, но явно больше подходит для написания рест-сервера, чем ручная возня).
Хотя буквально через 5 минут нашел разгромную статью про использование WCF для таких целей. Так что есть большое пространство для выбора любой понравившейся реализации.
Все прекрасно заводится на MVC Core + Kestrel/WebListener. WCF в 2016 году советовать для REST вообще издевательство :) Как по удобству так и по производительности. WCF только для легаси SOAP сейчас годится.

Не путайте энтерпрайз и легаси.


Логично, что библиотека, которую делали для SOAP — для него и годится.

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

Библиотеку делали не для SOAP, а как общую абстракцию над разными протоколами и транспортом.
Вот только общую абстракцию выбирали под SOAP. Взять хотя бы «перечисление» EnvelopeVersion с вариантами Soap11, Soap12 и None. То есть варианты конвертов, отличные от SOAP, не рассматриваются в принципе.

— Наезд на производительность понятен — все-таки сериализатор с фиксированной структурой (такой как protobuf) всегда будет быстрее любого сериализатора в формат с расширяемой структурой (XML, JSON). Но с безопасностью-то что не так?
Как раз и полезли косяки из-за абстракции.

Даже простой json будет быстрее.

Нормальная безопасность с делегированием в другие секьюрити зоны с поддержкой токенов и федерации — Ws2007 биндинг. Он умирает при минимальной нагрузке.
Kerberos тут не спасет — не все машины в домене и в одной подсети.
Клиентский сертификат — пародия, а не Mutal TLS.
Логин/пароль вообще под запретом в межсервисном взаимодействии. как и апи ключи.
А как в json с безопасностью? :)

От чего умирает Ws2007 биндинг? Что такое, вашем понимании, минимальная нагрузка? Почему клиентский сертификат вы считаете пародией?
Причем тут Json? Просто обычные Http REST сервисы. Тип контента вторичен.
Отдельные IdP для каждой зоны + OpenIdConnect + федерация + кастомные гранты.
Делать это на WCF — ну его в попу. Еще и кросплатформенность как-то надо будет поддерживать.

1000 запросов в секунду и привет. Дикий оверхед по расходу compute и размер сообщения. Плюс необходимость устанавливать сессию. Микросервис на Kestrel с полпинка выдает 90к в секунду на средней десктопной тачке и упирается в процессор.

Когда будет полноценный mutal tls, тогда не будет пародией.
Что значит — «необходимость устанавливать сессию»? Кому она там у вас необходима?

Чем mutual tls неполноценен?

Вы можете назвать хоть одну конкретную проблему, кроме общих слов?
Почитайте как работает WS2007FederationHttpBinding в связке с SAML и TransportSecurity. Увлекательная штука.

mutal tls как раз полноценен.

Проблему чего? WCF? Неадекватный уровень абстракции, из которого вытекает все остальное. Тонна WS-* спек поверх только добавляет проблем, а не упрощает жизнь. И все это типа универсально до ужаса.
И что я там должен вычитать? Ладно, если аргументов у вас нет, не буду больше с вами спорить.
Просто я с WCF начинал работать давно, а последние проекты подразумевали возможность сервисов отдавать как в REST, так и в SOAP виде одни и те же данные. Поэтому выбор пал на WCF. ВебАпи мне не рекомендовали (ради интереса можно глянуть мнение Эспозито на эту тему), а кор только-только вышел, и вот на нем имеет смысл попробовать :)
Видел «это». WebForms в 2013 году уже должны были вас насторожить, как и использование WebClient. WebApi родился как раз из-за того, что команда разработчиков пришла к пониманию абсурдности таких абстракций над Http.
Не понял, при чем тут вебформы и веб-клинет. Последним я вообще никогда не пользовался (c HttpWebRequest пересел сразу на HttpClient), а про первые в посте не было и речи: просто наши внутренние службы кидаются REST-ом, а сторонние чуваки на C++ данные хватают через soap.

Так что я не знаю, почему вы вебформы вспомнили. Но к слову, интересно, как будет развиваться SharePoint, ведь недавно вышла 2016 версия…
Вы привели в пример статью Esposito.
Ну для тех, кто кроме соапа ничего не умеет — стоит отдельный интеграционный сервак. В основной код и внутри сети это не попадает и не ограничивает никак.
Как в 360 перепилят на SPA + Knockout или Angular2. Либо свой фреймворк, как в Visual Studio Online.
Просто нам было удобнее иметь один WCF-сервис, который умеет отдавать данные в любом формате, хоть REST, хоть SOAP. Минус один интеграционный сервак, тоже плюс.

А еще интересно, чем вы так недовольны в моих постах, что решили карму заминусить. Я лично ваши посты/карму не трогал.
Кастанул вам немного кармы на пару с другом :)

SOAP и REST — это теплое с мягким. SOAP — протокол, а REST — архитектурный подход, прибитый гвоздями к транспорту. Как раз попытка натянуть REST и послужила причиной появления WebApi(ножки у него как раз из WCF растут). На данный момент времени(2017 год) WCF в стоп листе для нового кода. В дальнейшем он не будет развиваться и останется только для legacy. От него будет жить только кусочек отвечающий за клиентскую часть — Тынц.
В подходе с унификацией есть свои минусы(у нас то же есть внутренние потребители и внешние интеграции).
— Обратная совместимость и версионирование.
Внутренний api surface мы можем менять как хотим, при этом не трогая внешние интеграции. А внешние интеграции просто адаптеры. На этом уже обожглись разок и четко разделяем public и internal.
— Внешний апи может не соответствовать внутреннему, например агрегируя данные из нескольких внутренних источников.
— Костыли выкидываются в интеграционный слой.
— Можно отдельно мастшабировать, выкидывать в дмз, делать кастомную аутентификацию.

Вот поэтому сейчас советовать WCF для REST это не очень красиво, так как менее опытные разработчики обожгутся, а потом будут рассказывать бредни всякие :(

SOAP — это формат, а не протокол. Кстати, в спецификации SOAP 2.0 я видел указания как его дружить с REST. Правда, зачем нужен SOAP без WS-Addressing — лично для меня загадка.

SOAP (от англ. Simple Object Access Protocol)
Единственное кроссплатформенное приложение на дотнете, которое я помню — это кейген для КПК, который также запускался и на ПК.
Sign up to leave a comment.