Насколько понимаю, приложение забанят даже если альтернативный способ покупки не будет доступен и упомянут в приложении, именно поэтому есть онлайн игры, для которых существует «родной» клиент например под андроид, но игроки вынуждены играть в отдельном загоне (сервера android-версии будут недоступны с пк- и apple-версии, с серверами apple-версии всё то же самое). Сделать-то так, чтобы юзер мог пользоваться своим аккаунтом с любой платформы можно, но только если с покупки например в apple-версии 30% шло яблоку а 30% гуглу, одновременно. И то же самое с покупок в ПК-версии, и даже с тех юзеров, которые не пользуются мобильной версией вообще. Тогда не забанят. Система эта обсурдна уже тем, что если популярных платформ будет не 2 а 4 (вернётся microsoft, да вылупится что-нибудь у китайцев) — разработчикам придётся платить владельцам магазинов 120% комиссии с каждой покупки ).
Абсолютное большинство софта написано не на ассемблере. Следуя вашей логике, на x86 у него тоже должна быть смешная производительность? Ведь при компиляции в x86-бинарники тоже никто кроме компилятора руками инструкции не транслирует.
Мало того, универсальность наслаивается. Надо написать универсальный интерфейс не только к матери, но и универсальный интерфейс к комбинации мать+проц и потом универсальный интерфейс мать+проц+видяха и снова возвращаемся к куче индивидуальных прог, только на этот раз слоем выше.
Но зачем писать комбинированные интерфейсы, если уже есть универсальные интерфейсы ко всему этому по отдельности? Скорее уж поверх простых универсальных интерфейсов городится что-то «умное и удобное» чтобы погромист мог вместо 20 простых строчек то же самое написать в одну стильную-модную строчку с замыканиями и регулярными выражениями. А потом поверх этого пишется обёртка для нового крутого паттерна, потом всё это запихивают в REST и микросервисы, потом на электроне фигачится специально обученная служба, которая умеет общаться с этим микросервисом с доступом к ней ну, например, через пакет на питоне. А ты потом сидишь и думаешь как всю эту радость дёргать из своего QT-приложения вместо того чтобы тупо прилинковаться к той, лежащей в глубине библиотеке, к которой когда-то накатали умный и удобный слой.
Можно было бы построить теорию заговора, что разработчики всех этих сотен фреймворков таким образом стараются повысить порог входа в программисты, чтобы профессия оставалась высоко оплачиваемой, но на самом деле имхо всё усложняется во имя простоты здесь и сейчас, и пофиг что будет потом и кто эти горы «кода» потом станет разгребать. Вот хочет чувак погромировать микроконтроллеры а знает только жабаскрипт — он не ассемблер или си учить будет — он вкорячит туда интерпретатор жабаскрипта. Потом на этом жабаскрипте запустят транспилированную в него версию JVM, поверх неё java-версию интерпретатора python… микроконтроллеру придётся иметь для этого на борту уже гигабайты памяти и кучу гигагерц, но всем будет пофиг, заказчикам скажут не быть нищебродами и купить новые железяки. А потом всю эту радость воткнут в умный утюг, чтобы управлять морганием кнопки питания и лезть зачем-то в wifi. А самое печальное что это только сейчас шутка, а вот лет через 5-10 уже не факт )))
Это каким идиотом нужно быть, чтоб надеяться что через 20 лет наколеночная поделка финского студента, которую он написал только чтобы позлить Таненбаума, будет работать на большинстве серверов и телефонов в мире ))) ;)
Иск по патентам на ПО не может не быть не абсурдным. И так будет как минимум до тех пор пока не станет невозможно получить патент на «способ решить проблему N» патентополучателем, который при этом сам понятия не имеет как эту проблему решать, а патент регистрирует чтобы застолбить идею и ждать дурачка, который её решит на самом деле.
У меня возникает ощущение что вы вкладываете в «асинхронный» какой-то магический смысл. Для меня смысл тут только один — если процесс вызвал асинхронную функцию — управление к нему вернулось сразу, и потом он другими функциями может также не блокируясь проверять результат. Так, в частности, работают обращения к асинхронному сокету. А вот для общения с wsgi мне известно лишь 2 способа. Первый это когда сервер запускает некий исполнимый файл, обычно python-скрипт, запускающий wsgi-объект и ждёт от него в stdout текст результата. Это НЕ асинхронно. И второй, когда веб-сервер работает как reverse proxy и через сокеты общается с wsgi-сервером приложений. Это асинхронно, но это http и этим сервером приложений может быть что угодно, в том числе и uWSGI, и апач и gunicorn, тысячи их. Так вот, может вы знаете ещё какой то вариант и именно о нём говорите? Просветите плз. Потому что пока ваши слова звучат как бессмыслица, ибо прямое общение с wsgi через его stdout не может быть асинхронным и nginx на этом вешается совершенно без проблем.
Я конечно не спец в nginx, но беглый гуглинг показывает что за годы ничего не изменилось и в 2017 например от юзеров по прежнему появлялись вопросы, мол, почему когда несколько клиентов обращаются к серверу всё сначала висит а потом разом выплёвывается и после разборок там оказывается что nginx ждёт когда uwsgi с чем то там на питоне ответит а в это время остальные клиенты стоят в очереди. Возможно, вы имели в виду вариант когда nginx общается с uWSGI не по протоколу uwsgi а по http, но тогда это мало отличается от работающего на втором слое апача. А про асинхронность — то, что там сокеты работают в асинхронном режиме никак не противоречит и даже подтверждает что работает сервер с ними в один поток и если в этом потоке что то подвиснет то подвиснут все клиенты разом.
Вы сравниваете тёплое с мягким, nginx не лучше и не хуже апача, он другой. Nginx обрабатывает клиентов однопоточно, это его одновременно и достоинство и недостаток. Сами подумайте что будет под нагрузкой если запросы исполняются движком сайта не очень быстро. Поэтому обычно наружу в интернет на сервере ставят nginx, который отдаёт статику а всё остальное проксирует апачу или ещё какому нибудь серверу на котором крутится сам движок.
Внезапно даже под вендами у большинства сервисов нет гуя. Про апач и процессы — апач уже очень давно умеет создавать воркеры в потоках а не процессах, и модель программирования тут ни при чём, все давным давно пишут многопоточность на pthreads, а fork используют только динозавры, пишущие на чистом си как диды.
Успокойтесь, просто это тот самый человек, который любит с утречка сказать себе «пришло время переустанавливать шиндовс» ). Кстати, если не в теме — погуглите эту фразу )))
Вы видели этот nginx вендовый? И комменитарий разработчиков о том, что это фактически другая, заново написанная программа, глючная и написанная только потому что их достали требованиями запилить nginx под венду?
Апач под вендой работает, да, но его запускают в основном только разработчики веб приложений, а всё потому что лицензия на windows server требует закупить дополнительных лицензий на количество пользователей, которые к этому серверу будут подключаться. Купить несколько миллиардов доп-лицензий на пользователей не хотите? Есть еще особая, специально обученная для веба версия вин-сервера, но она тоже не бесплатна.
Ответ edogs на комментарий
Но зачем писать комбинированные интерфейсы, если уже есть универсальные интерфейсы ко всему этому по отдельности? Скорее уж поверх простых универсальных интерфейсов городится что-то «умное и удобное» чтобы погромист мог вместо 20 простых строчек то же самое написать в одну стильную-модную строчку с замыканиями и регулярными выражениями. А потом поверх этого пишется обёртка для нового крутого паттерна, потом всё это запихивают в REST и микросервисы, потом на электроне фигачится специально обученная служба, которая умеет общаться с этим микросервисом с доступом к ней ну, например, через пакет на питоне. А ты потом сидишь и думаешь как всю эту радость дёргать из своего QT-приложения вместо того чтобы тупо прилинковаться к той, лежащей в глубине библиотеке, к которой когда-то накатали умный и удобный слой.
Апач под вендой работает, да, но его запускают в основном только разработчики веб приложений, а всё потому что лицензия на windows server требует закупить дополнительных лицензий на количество пользователей, которые к этому серверу будут подключаться. Купить несколько миллиардов доп-лицензий на пользователей не хотите? Есть еще особая, специально обученная для веба версия вин-сервера, но она тоже не бесплатна.