Из статьи вообще нет ничего относящегося к нейронкам и ML, просто взяли готовые библиотеки, нормализовали / адаптирован и данные под запросы в Внешний сервис chatgpt и получили результат. Т. е отчёт бьётся на промты к чатгпт. А вывод сделанный ботом про выживаемость на основе табличного отчёта это задача в эксельке для преобразования отчёта в диаграмму по которой можно сделать вывод выведя диаграмму. Т. е главный продукт должен быть на самом деле конвертатор табличек в график/диаграмму, а не в текст.
Попробовал расширение. Видна вкладка записи и другие вкладки . Если другие вкладки окткрываем/закрываем, то запись продолжается. А когда останавливаем запись через кнопку Завершить, то вкладка записи закрывается. Удобное расширение. Мне понравилось.
область топ - это субъективная оценка, которая может быть трансформирована в "серьёзность оценки" по таким критериям как: кол-во рабочих мест(вакансий), уровень образования, транспортная доступность, кол-во фитнес центров/кружков для детей/занятий/скейтпарков/парков для прогулок, кол-во квадратных метров жилья, уровень заработной платы и т.д. И это можно проверить на более авторитетных источниках чем osm. Поэтому top - это серьёзная оценка показывающая превосходство по субъективным критериям. А у каждого критерии для комфорта разные. Кстати темпартура воздуха это тоже критерий. Невыносимая жара (или уровень ультрафиолета) 3-4 месяца в году для кого-то может быть топ, а для кого-то не топ. Поэтому серьёзность оценки у каждого своя. А ещё OSM это самый последний источник по которому можно что то анализировать. В OSM щас нет никаких правил, можете поискать там и пропаганду на мелких масштабах и ошибки. Поэтому сама серьёзность построения модели на основании случайных данных - это отрицательный топ.
И использовать пару-тройку критериев для построения моделей - не имеет смысла. Меня позабавил критерии про комаров.Зелёные квадратики возле реки Сочи.
Я прожил в Сочи 5 лет (переезжал из Балашихи). Снова вернулся в Балашиху. Могу сказать что ваша модель показала центральный район Сочи и эти вычисления мест можно было бы сделать не прибегая к вашей модели.Достаточно проанализировать трафик в соц.сетях и новостях и почитать историю города. Ещё в новостях есть статистика по затоплениям, но даже она даёт сбой. Например в 2022 затопило центральный район в ваших зелёных точках автомобили ушли под воду по окна и затопило подъезды и пешеходные переходы. И дело тут в застройке, уклонах и наличии автомобилей например в момент ливня, а также наличие забитой/или не забитой ливнёвки или частного какого нибудь строения которое там не должно быть. А ещё в Сочи (основной) пешеходный мост могут ремонтировать 2 года. Это ваша модель не предскажет. Любой ремонт это изменение трафика. В общем ваша модель даже примерно не даст вам ответа. Это всё бред. - потому что вокруг вас люди, а они не подчиняются таким простым моделям. Например вы не учитывайте в вашей модели трафик людей, пивнушки, кафешки и магазины, вам в зелёной точке возле грузинского кафе с магнитом и столовкой будет "очень комфортно", также модель не может учитывать соседей (и туристов арендующих жильё рядом с вами) и управляющую компанию или качество вашего дома (стены). Не учитывайте вроде бы простые вещи типо "школа рядом". Не учитывайте того кто будет вам сдавать квартиры, не учитывайт старые детские площадки в центре города на которых тусуются неадекватные подростки, не учитывайте что могут быть "локи" в виде шлагбамумов и невозможность подъехать, неучивайте неадекватные ремонты объёктов на улице, которые приводят к изменению всей соц. обстановки вокруг вашего "зеленого квадратика", неучитывайте вывоз мусора (в центр например на островского мусор вывозят часто и ночью и если у вас дом с окнами хотя бы в эту сторону, то будет весело), не учитывайте трансформаторные станции которые гудят, опорные стены которые рано или поздно упадут на ваш авто и т.д. Там куча всего. Мск и мск область это топ после сочи.
Правильно будет в коде для работы с репозиторием убрать info ключ.
Вот тут src/Composer/Repository/ComposerRepository.php добавить код начиная с 1479 строки включительно
$data = $response->decodeJson();
// repo.packagist.org отдаёт json с info с этой фразой
if(isset($data['info']))
{
$data['info'] = '';
}
Таким образом убираем пропаганду без пропаганды внутри исходного кода
С автором статьи согласен. Пропаганде не место в программном обеспечении. Это уже токсичный софт, который ничем не отличается от рекламы и вирусов. И неважно насколько "правильная" там пропаганда или реклама. Все люди разные и отношение у всех к происходящему разное.
Согласен. Gitlab и все продукты на руби - это тормозные и затратные по ресурсам системы. Альтернатива - gogs, gitrea. Всё бесплатно и открыто. Нужные фичи можно самому доделать. Мне страшно представить сколько gitlab тратит денег на свои сервера. Там такой аппетит по памяти и CPU будет, что наверное вся прибыль съедается только на серверной инфраструктуре. Не даром твиттер в своё время ушёл от руби.
Предлагаю вам выкурить 100 пачек сигарет через "не могу", тогда вы не будете безмозглой скотиной или спрыгнуть с крыши ради общего блага, чтобы уменьшить загрязнение нашей планеты посредством сокращения выбросов углекислого газа. А я останусть безмозглой скотиной и буду делать то что хочется,в рамках правовых, общественных и моральных норм, а не ради общего блага.
Зачем кататься на велосипеде просто так по парку? Зачем гулять по парку с собакой? Зачем делать что-то? Вот так выглядит ваша статья. Краткий ответ: потому что хочется, вот и всё.
А если нужно внести правки? Нужно будет 3 разработчика которые на 3-х проектах будут вносить правки
Ответ на этот вопрос зависит от преследуемых вами целей. В статье не подходящий пример. И KMM не вышедший до сих пор из беты доказывает его спорное положение. Дело как раз таки в том что у вас могут быть разные API версии, SDK платформ и окружений. В простейшем случае, как в вашей статье, всё очень просто и действительно можно заменить на 3-х проектах всё одним разработчиком при условии что он будет знать ГДЕ вставлять ваш SDK и какие структуры формировать для вашего SDK. Вам придётся в любом случае сформировать протокол/документацию. Отсюда вытекает следствие что разрабатывая такое SDK вы освоили swift/js/kotlin на том уровне, на котором KMM уже теряет смысл.
Чтобы было понятно у нас команда из 3-х человек на SDK, при этом SDK использует 7 проектов. Если предположить что чтобы это все сделать нужно по 3 человека на каждый проект то получается без SDK нужно было бы 21 разработчик.
Можно взять протокол/алгоритм SDK и сделать на 3 языка (swift/js/kotlin) и у вас будут независимые версии для платформ. 3 разрабочика их будут поддерживать. Каждому по одному ЯП. Стоит заметить что зная kotlin, выучить swift или js - это дело 1-2 дней. И в обратную сторону тоже самое. Особенно с современными IDE.
Так же формат данных между этими проектами тоже единый, введение новых фич одинаково для всех.
Не согласен. Ведь входные данные будут приходить из разных платформ. В любом случае надо будет изучить как эти данные прокинуть в SDK. В общем это похоже на всё то что уже было сделано до KMM. Та же концепция биндингов, только ещё более усложняющая поддержку (конвертацию кода в платформы)
Если проект "крестики-нолики" то конечно нет смысла тянуть мультиплатформу, но если у вас крупный enterprise проект со сложной логикой - то это просто must have.
Это субъективно, сложная логика она для всех разная =) Тем более я бы не стал доверять сложную логику автоматическому транслятору kotlin->swift , kotlin->js. Как раз таки тут лучше всё контролировать, раз это сложный и кровавый enterprise =)
Но оговорюсь это лишь моё личное мнение, возможно вам так удобнее, вы так решили и вас никто не остановил, потому что кроме вас знающих kotlin никого не было рядом, поэтому выбор был сделан верно или неверно. Но в статье всё переплетено в кучу. Вы в том числе упомянули react native и webview. И в общем, что вы это рассматривали, это наводит на мысль о том что вы хотели сделать cross, но увидели kmm, и побежали в него =)
Так что на счет минусов не уверен, и мое мнение что плюсы значительно их превышают.
После прочтения статьи у меня такого впечатления не создалось.
B ещё в вашем примере с крестиками-ноликами Game framework можно заменить на спецификацию или протокол и написать в каждом приложении код на нужном языке. А при использовании KMM, если кто-то будет сопровождать Game framework из примера, то ему придётся производить тестирование на N-платформ(языков). Именно поэтому KMM обречён только на очень узкие задачки, т.к если мы можем написать SDK на одном языке, то переписать его на swift / java / js - задача аналогичная компетенциям KMM, а вот вопрос надёжности кода и влияния на обновления при KMM вызывает больше опасений, в том числе по стоимости поддержки. К тому же усложняется раскатка обновлений или например частичных обновлений. В том числе изолированной работе над частями проекта. В общем очень много минусов.
Какой есть общий недостаток у мобильной, front-end и back-end разработки и иногда распила микросервисов? Дублирование логики
Зачем мне бекенд когда он не нужен?
Затем вы в пример приводите приложение без бекенда =)
Далее я постараюсь продемонстрировать, как на практике можно применить эту технологию. Для этого я написал ядро игры крестики-нолики и реализовал отображение на трех языках JS (Browser), Swift (iOS), Java (Android).
Я поясняю что в вашем примере всё можно сделать на flutter и как вы верно заметили без бекенда =), но можно и с бекендом =) Т.к вы указали backend-разработку и дублирование логики.
Как я и написал эту статью чтобы показать что иногда логики могут пересекаться, и что с помощью данной технологии проблему синхронизации можно избежать
У Вас статья начинается с "дублирования логики frontend-а и backend-а". А в примере вы уже обращайтесь к проблеме единой кодовой базы (кросс-платформенной разработки). Если вы о кросс-платформе, то как раз таки kotlin multiplatofrm не для этого, т.к интерфейс в том же iOS вы будете рисовать в xcode и собирать всё будете там, т.к в km нет единых инструментов сборки под разные платформы, в отличии от flutter.
Нужно понимать разницу в cross platform vs multiplatform.
Обратите внимание, если входим по номеру телефона, то он пытается сопоставить vk аккаунт и если ответить что это не мой аккаунт, то в vk аккаунте будут выполнены действия в соц.сети вконтакте:
Отключена функция подтверждения входа
К странице ВКонтакте не привязан телефон
Изменение номера мобильного телефона
Просто это странно, я вроде бы вхожу в отдельное приложение, но оно влияет на другие настройки.
Мне кажется это баг или хотя бы надо добавлять предупреждение. Человек может ошибиться и нажать случайно на эту кнопку, а она ему сбросит всё.
Какой есть общий недостаток у мобильной, front-end и back-end разработки и иногда распила микросервисов?... Очень часто логику работы приложения нужно поддержать и там
Мне кажется это проблема архитектуры, а не технологий. Моб приложение с северной логикой это тонкий/толстый клиент, который рисует только экраны, графику и работает с сетью, зачем мне там логика бекенда? или зачем на бекенде логика клиента, там же принципиально разные концепции,и всё равно придётся заботиться о синхронизации.
Мне кажется kotlin multiplatform узко специализированная технология , которая очевидно пока не нашла свою нишу.
В вашей статье всё можно сделать на flutter + любой бекенд, и это будет быстрее и понятнее, и легко поддерживаться, будет компилироваться на 2+ платформы без сюрпризов и без необходимости знаний в kotlin swiftui, javascript.
К тому же во flutter войти быстрее чем в jvm с котлином.
А еще мы можем передавать в новую функцию параметры роута, статус HTTP и дополнительные заголовки:
невероятно, в 2022 году в фреймворке для работы по HTTP проктолу теперь можно передавать заголовки ответа!!!! Браво! Рекомендую забыть этот фреймворк и обратить внимание на symfony, в котором всё что вышло ларе в 2022 году уже было в sf 10 лет назад.
Цену на билет на такой поезд надо тоже в копейках делать! Тогда будет true, иначе false весь этот перезапуск. Сэкономили просто на составе — сделав всё под «ретро». Такое ретро каждый день ходит на всех воказалах с Москвы. Лучше бы комфортный поезд сделали, а не это чудо ламповой эпохи.
Я еще раз повторюсь — этот код публикую для ответа на некорректную инфомрацию в статье о том что HTTP запросы можно обрабатывать 1 процессом. Некорректно сравнивать кол-во запросов на процесс, с кол-вом долгих процессов и асинхронностью в php.
Код веб сервера будет чуть посложней, но смысл тот же.
UPD: можно использовать встроенный в php web сервер для демонстрации
$ php -S localhost:3111 server.php
И обратитесь одновременно через curl -v localhost:3111
Также увидите что worker_id будет разный.
Для большей очевидности «асинхронности» можно добавить в server.php ответ
Phpfpm обрабатывает каждый запрос отдельным процессом.
Попробуйте запустите php-fpm с pm.static где будет 1 дочерний процесс. И выполните 2-4 HTTP запроса одновременно. И вы увидите что всё ок и ваше утверждение ложь.
А еще вы можете написать свой веб-сервер на php который будет обрабатывать одновременно >= 2 rps. Можно сделать его на чистом exec и pipeах. И всё это будет работать одновременно. Если нужно покрасивей и побольше контроля, можно взять pcntl. Но если вам нужно шарить данные между http запросами, вы можете использовать pthreads.
Делаем вывод что ничего в php гвоздями не прибито. Кроме того вы можете написать extension как на PHP, так и на C. И это будет очень быстрое решение.
Пожалуйста удалите статью или исправьте недочеты.
Не вводите людей в заблуждение.
Из статьи вообще нет ничего относящегося к нейронкам и ML, просто взяли готовые библиотеки, нормализовали / адаптирован и данные под запросы в Внешний сервис chatgpt и получили результат. Т. е отчёт бьётся на промты к чатгпт. А вывод сделанный ботом про выживаемость на основе табличного отчёта это задача в эксельке для преобразования отчёта в диаграмму по которой можно сделать вывод выведя диаграмму. Т. е главный продукт должен быть на самом деле конвертатор табличек в график/диаграмму, а не в текст.
Попробовал расширение. Видна вкладка записи и другие вкладки . Если другие вкладки окткрываем/закрываем, то запись продолжается. А когда останавливаем запись через кнопку Завершить, то вкладка записи закрывается. Удобное расширение. Мне понравилось.
область топ - это субъективная оценка, которая может быть трансформирована в "серьёзность оценки" по таким критериям как: кол-во рабочих мест(вакансий), уровень образования, транспортная доступность, кол-во фитнес центров/кружков для детей/занятий/скейтпарков/парков для прогулок, кол-во квадратных метров жилья, уровень заработной платы и т.д. И это можно проверить на более авторитетных источниках чем osm. Поэтому top - это серьёзная оценка показывающая превосходство по субъективным критериям. А у каждого критерии для комфорта разные. Кстати темпартура воздуха это тоже критерий. Невыносимая жара (или уровень ультрафиолета) 3-4 месяца в году для кого-то может быть топ, а для кого-то не топ. Поэтому серьёзность оценки у каждого своя. А ещё OSM это самый последний источник по которому можно что то анализировать. В OSM щас нет никаких правил, можете поискать там и пропаганду на мелких масштабах и ошибки. Поэтому сама серьёзность построения модели на основании случайных данных - это отрицательный топ.
И использовать пару-тройку критериев для построения моделей - не имеет смысла. Меня позабавил критерии про комаров.Зелёные квадратики возле реки Сочи.
Я прожил в Сочи 5 лет (переезжал из Балашихи). Снова вернулся в Балашиху. Могу сказать что ваша модель показала центральный район Сочи и эти вычисления мест можно было бы сделать не прибегая к вашей модели.Достаточно проанализировать трафик в соц.сетях и новостях и почитать историю города. Ещё в новостях есть статистика по затоплениям, но даже она даёт сбой. Например в 2022 затопило центральный район в ваших зелёных точках автомобили ушли под воду по окна и затопило подъезды и пешеходные переходы. И дело тут в застройке, уклонах и наличии автомобилей например в момент ливня, а также наличие забитой/или не забитой ливнёвки или частного какого нибудь строения которое там не должно быть. А ещё в Сочи (основной) пешеходный мост могут ремонтировать 2 года. Это ваша модель не предскажет. Любой ремонт это изменение трафика. В общем ваша модель даже примерно не даст вам ответа. Это всё бред. - потому что вокруг вас люди, а они не подчиняются таким простым моделям. Например вы не учитывайте в вашей модели трафик людей, пивнушки, кафешки и магазины, вам в зелёной точке возле грузинского кафе с магнитом и столовкой будет "очень комфортно", также модель не может учитывать соседей (и туристов арендующих жильё рядом с вами) и управляющую компанию или качество вашего дома (стены). Не учитывайте вроде бы простые вещи типо "школа рядом". Не учитывайте того кто будет вам сдавать квартиры, не учитывайт старые детские площадки в центре города на которых тусуются неадекватные подростки, не учитывайте что могут быть "локи" в виде шлагбамумов и невозможность подъехать, неучивайте неадекватные ремонты объёктов на улице, которые приводят к изменению всей соц. обстановки вокруг вашего "зеленого квадратика", неучитывайте вывоз мусора (в центр например на островского мусор вывозят часто и ночью и если у вас дом с окнами хотя бы в эту сторону, то будет весело), не учитывайте трансформаторные станции которые гудят, опорные стены которые рано или поздно упадут на ваш авто и т.д. Там куча всего. Мск и мск область это топ после сочи.
https://docker-mailserver.github.io/docker-mailserver/latest/
Правильно будет в коде для работы с репозиторием убрать info ключ.
Вот тут src/Composer/Repository/ComposerRepository.php добавить код начиная с 1479 строки включительно
Таким образом убираем пропаганду без пропаганды внутри исходного кода
С автором статьи согласен. Пропаганде не место в программном обеспечении. Это уже токсичный софт, который ничем не отличается от рекламы и вирусов. И неважно насколько "правильная" там пропаганда или реклама. Все люди разные и отношение у всех к происходящему разное.
Согласен. Gitlab и все продукты на руби - это тормозные и затратные по ресурсам системы. Альтернатива - gogs, gitrea. Всё бесплатно и открыто. Нужные фичи можно самому доделать. Мне страшно представить сколько gitlab тратит денег на свои сервера. Там такой аппетит по памяти и CPU будет, что наверное вся прибыль съедается только на серверной инфраструктуре. Не даром твиттер в своё время ушёл от руби.
Предлагаю вам выкурить 100 пачек сигарет через "не могу", тогда вы не будете безмозглой скотиной или спрыгнуть с крыши ради общего блага, чтобы уменьшить загрязнение нашей планеты посредством сокращения выбросов углекислого газа. А я останусть безмозглой скотиной и буду делать то что хочется,в рамках правовых, общественных и моральных норм, а не ради общего блага.
Зачем кататься на велосипеде просто так по парку? Зачем гулять по парку с собакой? Зачем делать что-то? Вот так выглядит ваша статья. Краткий ответ: потому что хочется, вот и всё.
Ответ на этот вопрос зависит от преследуемых вами целей. В статье не подходящий пример. И KMM не вышедший до сих пор из беты доказывает его спорное положение. Дело как раз таки в том что у вас могут быть разные API версии, SDK платформ и окружений. В простейшем случае, как в вашей статье, всё очень просто и действительно можно заменить на 3-х проектах всё одним разработчиком при условии что он будет знать ГДЕ вставлять ваш SDK и какие структуры формировать для вашего SDK. Вам придётся в любом случае сформировать протокол/документацию. Отсюда вытекает следствие что разрабатывая такое SDK вы освоили swift/js/kotlin на том уровне, на котором KMM уже теряет смысл.
Можно взять протокол/алгоритм SDK и сделать на 3 языка (swift/js/kotlin) и у вас будут независимые версии для платформ. 3 разрабочика их будут поддерживать. Каждому по одному ЯП. Стоит заметить что зная kotlin, выучить swift или js - это дело 1-2 дней. И в обратную сторону тоже самое. Особенно с современными IDE.
Не согласен. Ведь входные данные будут приходить из разных платформ. В любом случае надо будет изучить как эти данные прокинуть в SDK. В общем это похоже на всё то что уже было сделано до KMM. Та же концепция биндингов, только ещё более усложняющая поддержку (конвертацию кода в платформы)
Это субъективно, сложная логика она для всех разная =) Тем более я бы не стал доверять сложную логику автоматическому транслятору kotlin->swift , kotlin->js. Как раз таки тут лучше всё контролировать, раз это сложный и кровавый enterprise =)
Но оговорюсь это лишь моё личное мнение, возможно вам так удобнее, вы так решили и вас никто не остановил, потому что кроме вас знающих kotlin никого не было рядом, поэтому выбор был сделан верно или неверно. Но в статье всё переплетено в кучу. Вы в том числе упомянули react native и webview. И в общем, что вы это рассматривали, это наводит на мысль о том что вы хотели сделать cross, но увидели kmm, и побежали в него =)
После прочтения статьи у меня такого впечатления не создалось.
Но спасибо вам за разбор и ответы.
B ещё в вашем примере с крестиками-ноликами Game framework можно заменить на спецификацию или протокол и написать в каждом приложении код на нужном языке. А при использовании KMM, если кто-то будет сопровождать Game framework из примера, то ему придётся производить тестирование на N-платформ(языков). Именно поэтому KMM обречён только на очень узкие задачки, т.к если мы можем написать SDK на одном языке, то переписать его на swift / java / js - задача аналогичная компетенциям KMM, а вот вопрос надёжности кода и влияния на обновления при KMM вызывает больше опасений, в том числе по стоимости поддержки. К тому же усложняется раскатка обновлений или например частичных обновлений. В том числе изолированной работе над частями проекта. В общем очень много минусов.
Я вас процитирую на всякий случай =)
Затем вы в пример приводите приложение без бекенда =)
Я поясняю что в вашем примере всё можно сделать на flutter и как вы верно заметили без бекенда =), но можно и с бекендом =) Т.к вы указали backend-разработку и дублирование логики.
У Вас статья начинается с "дублирования логики frontend-а и backend-а". А в примере вы уже обращайтесь к проблеме единой кодовой базы (кросс-платформенной разработки). Если вы о кросс-платформе, то как раз таки kotlin multiplatofrm не для этого, т.к интерфейс в том же iOS вы будете рисовать в xcode и собирать всё будете там, т.к в km нет единых инструментов сборки под разные платформы, в отличии от flutter.
Нужно понимать разницу в cross platform vs multiplatform.
Обратите внимание, если входим по номеру телефона, то он пытается сопоставить vk аккаунт и если ответить что это не мой аккаунт, то в vk аккаунте будут выполнены действия в соц.сети вконтакте:
Отключена функция подтверждения входа
К странице ВКонтакте не привязан телефон
Изменение номера мобильного телефона
Просто это странно, я вроде бы вхожу в отдельное приложение, но оно влияет на другие настройки.
Мне кажется это баг или хотя бы надо добавлять предупреждение. Человек может ошибиться и нажать случайно на эту кнопку, а она ему сбросит всё.
Мне кажется это проблема архитектуры, а не технологий. Моб приложение с северной логикой это тонкий/толстый клиент, который рисует только экраны, графику и работает с сетью, зачем мне там логика бекенда? или зачем на бекенде логика клиента, там же принципиально разные концепции,и всё равно придётся заботиться о синхронизации.
Мне кажется kotlin multiplatform узко специализированная технология , которая очевидно пока не нашла свою нишу.
В вашей статье всё можно сделать на flutter + любой бекенд, и это будет быстрее и понятнее, и легко поддерживаться, будет компилироваться на 2+ платформы без сюрпризов и без необходимости знаний в kotlin swiftui, javascript.
К тому же во flutter войти быстрее чем в jvm с котлином.
невероятно, в 2022 году в фреймворке для работы по HTTP проктолу теперь можно передавать заголовки ответа!!!! Браво! Рекомендую забыть этот фреймворк и обратить внимание на symfony, в котором всё что вышло ларе в 2022 году уже было в sf 10 лет назад.
Я еще раз повторюсь — этот код публикую для ответа на некорректную инфомрацию в статье о том что HTTP запросы можно обрабатывать 1 процессом. Некорректно сравнивать кол-во запросов на процесс, с кол-вом долгих процессов и асинхронностью в php.
Через 5 секунд появится файлик test.log.
Можете запустить из >= 2 терминалов и увидите
Код веб сервера будет чуть посложней, но смысл тот же.
UPD: можно использовать встроенный в php web сервер для демонстрации
И обратитесь одновременно через curl -v localhost:3111
Также увидите что worker_id будет разный.
Для большей очевидности «асинхронности» можно добавить в server.php ответ
Попробуйте запустите php-fpm с pm.static где будет 1 дочерний процесс. И выполните 2-4 HTTP запроса одновременно. И вы увидите что всё ок и ваше утверждение ложь.
А еще вы можете написать свой веб-сервер на php который будет обрабатывать одновременно >= 2 rps. Можно сделать его на чистом exec и pipeах. И всё это будет работать одновременно. Если нужно покрасивей и побольше контроля, можно взять pcntl. Но если вам нужно шарить данные между http запросами, вы можете использовать pthreads.
Делаем вывод что ничего в php гвоздями не прибито. Кроме того вы можете написать extension как на PHP, так и на C. И это будет очень быстрое решение.
Пожалуйста удалите статью или исправьте недочеты.
Не вводите людей в заблуждение.