автор сам сначала не понял, в чём дело.
Ну и потом, ошибка (или "баг") - это когда программа работает не так, как от неё ожидал разработчик. Если программа работает так, как ожидается, но это ожидаемое поведение может вести к нежелательным последствиям - это не ошибка, это уязвимость.
теперь понял, что это именно сервис на уровне ОС, а не библиотеки php внутри приложения. Спасибо)
Это уже пошли выкрутасы.
Вот только он против современного так называемого ООП. Его слова: "Я придумал термин ООП, но не имел ввиду C++". Есть еще его высказывания подобной направленности.
И чем же ФП сложное? С любой стороны ФП проще. Потому что Лямбда-исчисление само по себе простая модель. Может ли быть полноценный удобный язык проще чем Лисп? Идея о том, что приложение это просто функция - простая. Даже такие сложные приложения как компиляторы/интерпретаторы прекрасно реализуются в таком стиле. Можно легко разложить такое приложение на функции и держать все это в голове. Подобное приложение в стиле современного ООП будет монструозным и запутанным, его невозможно будет держать в голове.
Человек - не машина. Инструкции не любят читать и плохо понимают. Потому что императивность. Декларативный язык математики понимают намного большее количество людей.
Это не означает, что идея не дурацкая. Повсеместно - значит используется большинством. Большинство - всегда ошибочно, потому что нет своего мнения, потому что толпа, у толпы нет интеллекта. Все побежали и я побежал. Самые лучшие идеи всегда не находятся на поверхности.
websocket это расширение http запроса, т.е. там добавляются специфические заголовки и можно отправлять туда-сюда пакеты в одном соединении.
Не только я плохо отзываюсь о так называемом ООП, но и многие всемирно известные деятели в IT. Не только Дейкстра. Нужно привести их имена?
По вашему современная индустрия лучше во всем разбирается чем лауреаты премии Тьюринга?
Есть универсальные критерии для оценки. Простое лучше сложного. ФП - простое, ООП - сложное. Чем меньше кода - тем меньше проблем. ФП - мало кода, ООП - много кода.
Человек не приучен мыслить в моделях вычислений с состояниями. Зато с детства приучается мыслить в аппликативных моделях вычислений. Потому ФП - естественная модель программирования, а ООП - нет.
У большинства нет своего мнения. Они просто следуют за кем то. Так было и будет всегда. Поэтому аргумент большинством - не аргумент.
Большинство не могут ошибаться?
Он только выглядит понятным. Такой код состоит из множества запутанных изменяемых состояний, а это зло. Никакого выигрыша не дает, только усложняет, прибавляет лишнего кода.
Известная мантра. Любой реальный пример ее опровергает.
Не имеет значения. Никогда FPM даже не приблизится к производительности workerman или подобных апликейш серверов.
Не знаю, не тестил, но вообще, сервера на C++ могут быть медленнее серверов на Go. И даже медленнее серверов на Node.js (uWebsockets.js). Просто потому, что хуже написаны. Вы ведь не заботитесь о производительности, правильно понимаю? И другие не заботятся. Просто пишут код и всё. Опытных системных программистов мало. Поэтому в 2025 году большинством используется устаревший во всех смыслах FPM. Заметьте, большинством. Так как большинство всегда ошибочно
Смотря что понимать под сайтом. И смотря как будет устроен этот сайт. Блог это сайт? Блоги на Next.js даже без оптимизаций значительно производительней чем такие же, использующие php-fpm.
Так это на 1 ядре! На 8 ядрах ~300-400к rps. То есть во много раз превосходит fpm + nginx. И это всего лишь hello world. Будь что сложнее, fpm и 1000 rps не покажет. Это вообще смешно.
За столько Next.js полноценную страницу отрисовывает.
FPM в реальных приложениях показывает <1000 rps и все другие показатели соответствуют. Это как сравнивать скорость велосипеда и автомобиля.
Это невозможно сделать, обладая лишь ограниченными привилегиями в рабочей системе (другие уязвимости в расчет не берем).
ошибка в ПО - это когда ПО работает не так, как ожидается. Здесь нет такой ситуации. Никакой существенной уязвимости здесь также нет, поскольку для возможности получить полные привилегии в системе - ими уже надо обладать на подготовительном этапе.
От борьбы же с ветряными мельницами в лучшем случае не бывает пользы. Обычно же бывает лишь вред.
наши вам соболезнования.
эксплойт и баг это вещи, зачастую никак друг с другом не связанные.
И здесь нет возможности эскалации привилегий пользователя.
Он оттуда может права себе повысить до админских и запустить любой экзешник
чушь. Здесь нет никаких "ошибок", про права вообще какие-то ахинея.
если у тебя есть физический доступ к машине, и данные на ней не зашифрованы, то у тебя полностью развязаны руки...
Я вас огорчу, но в линуксе тоже есть подобный обход достаточно поправить загрузчик и вы рут пользователь
Видимо Дейкстра был прав, сказав, что ООП плохая идея, которую могли придумать только в Калифорнии.
Код в ООП стиле сложно понять. По крайней мере мне
Откройте Techempower benchmark. Вчера тестировал workerman с помощью wrk, на одном ядре 50 000 запросов в секунду, на нескольких ядрах сотни тысяч. FPM с Nginx и стандартными настройками показывает 4 500 запросов в секунду.
Буду разбираться. Посоветуйте что нибудь практичное для обучения. Чтобы по больше практики. От толстых книг клонит в сон.
учить вежливости незнакомых людей - это как раз неуважение. А учитывая, что они еще, скорее всего, старше и опытнее - просто глупость.
Как дальше с этим жить и лопатить проекты с JOIN'ами(это грубо говоря) при переносе?
а сколько должно быть?
10М в день - это 3 650М в год, у вас за выбранный год по выбранным датчикам - 366М, это не корректно?
Вас смущает именно кол-во прочитанных строк, или все таки скорость? Могу ошибаться, но что касается скорости, то мне кажется странным выбранный primary key, при нем гранулы будут слишком маленькими.