Василий Банников

Корутины в Unity придуманы были, из-за отсутствия вменяемой асинхронности в шарпе древние времена, причем сами корутины завязаны на жизненный цикл приложения Unity. Нужна асинхронность, есть async/await, параллельность - TPL (Task Parallel Library).

https://learn.microsoft.com/en-us/dotnet/standard/...

1. Минимальная скорость. Скорость интернета для юр.лиц является "гарантированной", как результат там должен быть меньше оверсэйлинг.
2. Поддержка. Поддержка для юр.лиц более оперативная и обладает большими полномочиями.
3. Финансовое и юридическое сопровождение. Банальная выписка документов и их доставка тоже стоит денег, правки в договора и т.п. Да, возможно конкретно вас устраивает стандартный договор, но содержание юр.службы размазывается на всех клиентов.
4. География подключения, юр.лица часто подключаются или в отдельно стоящих зданиях, или в бизнес центрах.
И то и другое тот еще квест, включающий аренду столбов и канализации. Плотность подключения абонентов так же ниже. Как пример, обрыв оптической линии, физ.лица в девятиэтажке, починили, решили проблему для сотни абонентов, юр.лицо в бизнес центре, починили, помогли десятку абонентов. Объем работы одинаковый, но в первом случае размазан на 100 договоров, а во втором на 10.
5. Ниже конкуренция. Физлицо проще меняет провайдера, у юр.лица это целый квест, не переносимые телефонные номера, юридические требования к договору, требования к контрагентам, монополизация физического доступа в здание( бизнес центром или владельцем тех же столбов и канализации ).
6. Более длительный цикл сделки с более высокими требования к сотрудникам эту сделку проводящим, отдел продаж тоже хочет кушать.
7. Чувствительность клиента к цене. Если физ.лицо, может сменить провайдера из-за 100 рублей в месяц, юр.лицо таким заниматься не будет даже за 5000 рублей, а крупное и за 100.000 рублей. Да, на этапе заключения договора цена будет иметь значение, но дальше про нее все забудут.

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

все это есть на сайте мегафона. если у них предусмотрен просмотр с ПК(что скорее всего), там должна быть инструкция и плейлист

.Replace("\"","")

Что вы лезете в то Unity, когда основ C# не знаете?

При включении с помощью include так и делают, т.к. для включенного makefile текущим каталогом будет каталог откуда вызван первичный makefile, а отсюда файлы в подкаталоге доступны только с указанием пути. include же по сути просто вставляет текст одного файла в другой и все.
Другой вариант - не использовать include, а запускать make рекурсивно для каждого подкаталога с переходом в этот подкаталог (вроде ключ -с в make).

Ускорение: a=v/t
Расстояние: s=at^2/2

t= 11 сек
v= 100 км/ч = 27.777(7) м/с

Подставьте сами

Начну с конца - для индексов это критично разные вещи. Планировщик даже пытаться анализировать не станет, эквивалентные это условия или нет. Если у вас есть индекс по my_column -> 'a', а в запросе вы написали "my_column"['b'] - то этот индекс использоваться не будет.

Касательно самих двух операторов:
-> ровесник jsonb как такового
jsonb[element] - jsonb subscripting на языке документации - штука недавняя, лишь только прошлогодняя из pg14. Пока что нужно иметь в виду если вам может потребоваться более старая версия базы.
По поведению отличий вроде не должно быть никаких. Оба варианта возвращают jsonb, поэтому IRL куда чаще используется ->> возвращающий текст.
На уровне реализации оба приходят к одному и тому же getKeyJsonValueFromContainer. Вы скорее упрётесь в производительность разбора формата самого jsonb, чем заметите какую-то разницу в производительности родного оператора от type subscripting.