Как я понимаю, речь и не шла про отсутствие выбора. Скорее про упрощение этого выбора — чтобы конкуренция шла по меньшему количеству факторов (в идеале — только по цене, то есть с возможностью напрямую сравнить стоимость за идентичные пакеты услуг), а не по большущему списку разных бонусных и прочих программ, делающих предложение, во-первых, шире того, что нужно потребителю, а во-вторых — почти несравнимым с предложением другого бизнеса, так как у них свои программы с другими условиями.
По мнению Ричарда Кордрея, ситуация приводит к тому, что зачастую потребитель не может трезво оценить, какое предложение ему подходит лучше, и потому при выборе поддаётся эмоциям, а это позволяет бизнесам его «разводить».
Вы же предлагаете убить [раз?]нообразие и лишить клиента выбора.
Что вы думаете про цитату внизу?
If [the sellers] can confuse the consumer enough then the consumers won't necessary know what choice they're making and they can be talked into just about anything.
— Richard Cordray, director of Consumer Financial Protection Bureau
Тут стоит ещё помнить, что HDMI имеет ещё и версию, так что просто смотреть на фактическое наличие разъёма недостаточно.
Например, википедия утверждает, что USB T-C поддерживает только HDMI-1.4 (это при живом стандарте HDMI-2.1). Впрочем, там же написано, что вообще скорость соединения составляет порядка 20 Gbit/s, так что там теоретически можно уместить HDMI-2.0 (нужно 18 Gbit/s), а при использовании коротких (или активных) кабелей — скорость можно поднять по 40 Gbit/s, а это всего чуть-чуть не дотягивает до HDMI-2.1 (нужно 48 Gbit/s).
Если смотреть по годам разработки, то Type-C стандартизирован на год позже, чем HDMI-2.0, и на три года раньше, чем 2.1.
Обычно это две коробки с антеннами, одна ставится возле проектора (и подключается к нему HDMI-кабелем). Вторая — где-нибудь в удобном месте, скажем, в середине стола, и также имеет «хвост» для подключения HDMI. То есть, так решается исключительно проблема провода посередине, начало и конец при этом достаточно обыкновенные. Чтобы не уносили из переговорки (если это проблема), можно «прибить гвоздями».
Вот, один из примеров того, как это может выглядеть ссылка. Есть варианты с «флешками» вроде вот такого, но вот их-то как раз кто-нибудь может и унести.
В конце концов, есть уже давно рабочие варианты пустить HDMI вообще по воздуху — достаточно прикрутить по небольшой коробочке возле проектора и «в штатном месте», последняя миля с обоих сторон по короткому кабелю. И никакой капремонт не понадобится.
Ну если в вашей версии ЕЕ есть такой флаг в принципе, то отсутствие его правильной поддержки в вашем контейнере — это критический баг контейнера, его тогда не имеют права (ага-ага) сертифицировать как поддерживающий данную версию ЕЕ. Но посыл сам по себе мне понятен.
Ну вообще варианты есть, но их теперь сложнее находить из-за моды на декларативность. Backbone, Ext JS, например — императивныe (хотя довольно много кода на ExtJS, скажем, может выглядеть как декларация, из-за того, что основная стратегия расширения — через кучу плагинов и кастомные события). Но кто про них сейчас говорит?
Думаю, фишка в том, что на императивных фреймворках типичные "магические" примеры с <p> и <input> в духе "вот тут пишете, в вот тут само(!) магическим образом обновляется" писать не так интересно, потому что все необходимые для магии обработчики событий не будут спрятаны в недрах фреймворка, а потому не будут вызывать такого вау-эффекта.
Как я понимаю, в EE это решается тем, чтобы сделать таймер
persistent = true
— тогда он хранится где-нибудь на диске (может в базе данных, на усмотрение контейнера), и транзакционно меняет состояние на "запущенный" когда его кто-то начинает выполнять. При условии, что обе ноды имеют общий persistence-store, вторая нода уже не станет его подбирать.
Да, я понимаю. Моё замечание было про то, что пользоваться этим можно научиться достаточно быстро (а если честно, то и не нужно толком даже осваивать, большинство решений можно собрать по копипасте из документации и со StackOverflow), но вот чтобы сказать, что ты по Spring освоил EE — нужно переварить сверху ещё кучу сценариев использования, которые в Spring зачастую даже отсутствуют (i.e. EE Timers).
Всё же различные ангуляры и диалекты реакта в моих глазах не являются заменой GWT, потому что у них явный уклон в декларативное описание интерфейса, а GWT — это, по большей части, императивщина. Потому если уже есть работающий и, по своей сути, императивный код работы интерфейса, переписать его на что-то декларативное это работа весьма неблагодарная, хотя и реальная.
Тем не менее, я всего полгода назад столкнулся с въедливостью экзаменаторов по EE.
Казалось бы, чего я там, натурально, не знаю, если я, фактически, в этом кровавом энтерпрайзе, работаю? Но как оказалось, для того, чтобы писать что-то нестыдное с использованием EE, знаний нужно по крайней мере вполовину меньше, чем чтобы получить лычку. Может, это поменяют в будущем, но пока что, по отзывам (и моему ощущению), по-прежнему сертификация от Oracle по EE — одна из самых сложных в индустрии.
Советский рубль 1970 года можно продать за современные рубли по курсу примерно 1 к 100, и уже на них купить кофе. Операция, конечно, не прямая, и с определёнными рисками, но говорить, что такие рубли не имеют ценности — неправильно.
Но нужны-то не нищие, а те, кто кредиты брать согласится, и как-то будет их отдавать потом. Нищий же либо просто не возьмёт, либо ему нечем будет отдавать.
Думаю, SQL — это жульничество, ведь там, по факту, реализацией алгоритма занимается демон-оптимизатор базы данных. Хотя это действительно отличный способ решить такую проблему.
Правда, про disjoint set индексы в базах я пока что не слышал. Может, просто плохо слушал.
Нет, я предлагаю смотреть с чуть другой стороны. Насколько помню, формат doc опубликован, «от доброты душевной». Не имеет смысла с точки зрения открытых инструментов этому формату следовать плохо, зато имеет огромный смысл с точки зрения Microsoft следовать формату «лучше». Например, я сталкивался с ситуацией: границы независимых таблиц были выровнены в MSWord, но отображаются с малюсеньким таким сдвигом в Libre. Я предполагаю, что в самом файле координаты границ в этих таблицах не равны, и Libre честно это отображает, а вот MSWord достаточно умён, чтобы «угадать» намерение пользователя и применить там дополнительное форматирование, хотя формально здесь они не следуют ими же опубликованному стандарту. Это, разумеется, только спекуляции, и вообще, надо на шапочку ещё слой намотать, а то блеск уже не тот.
А отношение про «стандарт — это то, что [только] мы используем» — очень полезное с точки зрения vendor lock-in, но крайне вредное для кооперации B2B, конкуренции в сфере услуг, и с точки зрения антимонопольных законов тоже.
По мнению Ричарда Кордрея, ситуация приводит к тому, что зачастую потребитель не может трезво оценить, какое предложение ему подходит лучше, и потому при выборе поддаётся эмоциям, а это позволяет бизнесам его «разводить».
Что вы думаете про цитату внизу?
Например, википедия утверждает, что USB T-C поддерживает только HDMI-1.4 (это при живом стандарте HDMI-2.1). Впрочем, там же написано, что вообще скорость соединения составляет порядка 20 Gbit/s, так что там теоретически можно уместить HDMI-2.0 (нужно 18 Gbit/s), а при использовании коротких (или активных) кабелей — скорость можно поднять по 40 Gbit/s, а это всего чуть-чуть не дотягивает до HDMI-2.1 (нужно 48 Gbit/s).
Если смотреть по годам разработки, то Type-C стандартизирован на год позже, чем HDMI-2.0, и на три года раньше, чем 2.1.
Вот, один из примеров того, как это может выглядеть ссылка. Есть варианты с «флешками» вроде вот такого, но вот их-то как раз кто-нибудь может и унести.
Ну вообще варианты есть, но их теперь сложнее находить из-за моды на декларативность. Backbone, Ext JS, например — императивныe (хотя довольно много кода на ExtJS, скажем, может выглядеть как декларация, из-за того, что основная стратегия расширения — через кучу плагинов и кастомные события). Но кто про них сейчас говорит?
Думаю, фишка в том, что на императивных фреймворках типичные "магические" примеры с
<p>и<input>в духе "вот тут пишете, в вот тут само(!) магическим образом обновляется" писать не так интересно, потому что все необходимые для магии обработчики событий не будут спрятаны в недрах фреймворка, а потому не будут вызывать такого вау-эффекта.Как я понимаю, в EE это решается тем, чтобы сделать таймер
— тогда он хранится где-нибудь на диске (может в базе данных, на усмотрение контейнера), и транзакционно меняет состояние на "запущенный" когда его кто-то начинает выполнять. При условии, что обе ноды имеют общий persistence-store, вторая нода уже не станет его подбирать.Казалось бы, чего я там, натурально, не знаю, если я, фактически, в этом кровавом энтерпрайзе, работаю? Но как оказалось, для того, чтобы писать что-то нестыдное с использованием EE, знаний нужно по крайней мере вполовину меньше, чем чтобы получить лычку. Может, это поменяют в будущем, но пока что, по отзывам (и моему ощущению), по-прежнему сертификация от Oracle по EE — одна из самых сложных в индустрии.
Правда, про disjoint set индексы в базах я пока что не слышал. Может, просто плохо слушал.
Звучит немного киберпанково, «микроволновые пушки на каждом столбе».
А отношение про «стандарт — это то, что [только] мы используем» — очень полезное с точки зрения vendor lock-in, но крайне вредное для кооперации B2B, конкуренции в сфере услуг, и с точки зрения антимонопольных законов тоже.