URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 116973
[ Назад ]

Исходное сообщение
"В PHP 8 будет добавлен JIT-компилятор"

Отправлено opennews , 31-Мрт-19 12:59 
Разработчики PHP официально утвердили (https://blog.krakjoe.ninja/2019/03/php-gr8.html) план включения JIT-компилятора в состав следующей ветки PHP 8, но отвергли прдлложение по интеграции JIT в следующий значительный релиз PHP 7.4. Перед выполнением PHP транслирует исходные тексты PHP-скриптов в промежуточное представление (байткод), которое затем выполняется в виртуальной машине Zend VM. JIT поможет дополнительно поднять производительность за счёт преобразования байткода в специфичный для текущей аппаратной платформы машинный код, который может напрямую исполняться процессором, минуя интерпретатор байткода в Zend VM.

При этом после внедрения JIT кардинального роста производительности для web-разработчиков  не предвидится, так как основным узким местом для большей части применяемых на сайтах PHP-скриптов является ввод/вывод (обработка сетевых соединений, чтение и запись файлов, обращение к СУБД, кэширование и т.п.), а не скорость выполнения на CPU.  В процессе разработки прошлого набора оптимизаций было выявлено, что типичное PHP-приложение тратит примерно 20% времени на выполнение задач менеджера памяти, 10% на обработку хэш-таблиц, 30% на вызов внутренних функций и только 30% на выполнение кода в виртуальной машине.


Тем не менее, внедрение JIT не лишено смысла, так как даёт возможность вывести PHP за рамки web-разработки, благодаря повышению производительности при выполнении таких задач как машинное обучение, математические расчёты, анализ данных, 2D- и 3D-рендеринг. В ходе разработки ветки PHP 7 была проведена (https://www.opennet.dev/opennews/art.shtml?num=39724)  оптимизация методов работы с памятью и организации хранения структур данных, что позволило значительно поднять производительность и в задачах, связанных с web-разработкой,  догнать, а в некоторых тестах  перегнать (https://kinsta.com/blog/hhvm-wordpress/), по производительности (https://kinsta.com/blog/php-benchmarks/) альтернативную виртуальную машину HHVM (https://www.opennet.dev/opennews/art.shtml?num=50133) для PHP, в которой применялась JIT-компиляция.


Теперь настал черёд оптимизации стадии выполнения. Так как интерпретатор байткода в Zend VM уже достаточно хорошо оптимизирован, предполагается, что JIT будет привлекаться только для выборочного выполнения конструкций, для обработки которых имеет значение производительность CPU, например, для кода, выполняющего интенсивные математические вычисления и обработку в циклах данных, находящихся в оперативной памяти.


URL: https://blog.krakjoe.ninja/2019/03/php-gr8.html
Новость: https://www.opennet.dev/opennews/art.shtml?num=50428


Содержание

Сообщения в этом обсуждении
"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 12:59 
Ой, все...

"В PHP 8 добавят закладку!!!"
Отправлено anoimouse , 01-Апр-19 09:05 
JIT использовать небезопасно! Использование jit запрещено главным правилом построения безопасной системы.

Призываю всех бойкотировать программы использующие jit.


"В PHP 8 добавят закладку!!!"
Отправлено funny.falcon , 01-Апр-19 14:31 
Т.е. предлагаешь выкинуть все андроид телефоны на помойку?
Хммм... а это мысль...
Не займёшь на iPhone до зарплаты?
Только Safari нужно будет отключить. Там ведь жабоскрипт с джитом.

"В PHP 8 добавят закладку!!!"
Отправлено freehck , 02-Апр-19 11:08 
> Призываю всех бойкотировать программы использующие jit.

Ну да, давай бойкотировать лиспы, яву...


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 03-Апр-19 16:01 
Лисп очень стар ижаба тоже. Функциональное программирование давние. Любимый питон тоже работает, только без функционального программирования.

Технология защиты памяти посегментно относительно нова, а реализация постраничной защиты памяти современными процессорами вообще новая и очень эффективная и экономичная технология безопасности.

Иначе как гарантировать неизменность исполняемого кода?

Исполняемому даем права X
Изменяемым данным W
Права WX - дыра позволяющая изменить исполняемый код. Нормальные процессоры такого не разрешают. Нормальные ядра ОС тоже.

Я не вижу другого пути гарантирования безопасности.

JIT - нарушает главное правило построения безопасной ОС.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 03-Апр-19 16:26 
> Иначе как гарантировать неизменность исполняемого кода?

Зачем это делать? Ну допустим мы сделаем код неизменным. Что в итоге? Прощайте функции первого порядка, да? Вернём старую добрую эпоху Си и Асма?

> Я не вижу другого пути гарантирования безопасности.

Другие пути есть. Если Ваша программа создаёт функции на лету по заранее определённым шаблонам, если производится строгий контроль типов на этапе компиляции -- то grsec/pax Вам вряд ли потребуются. Короче, возьмите Ocaml/Haskell.

> JIT - нарушает главное правило построения безопасной ОС.

Ничего он не нарушает, расслабьтесь. Мандатный доступ имеет смысл только для низкоуровневых языков, типа Си.

Ну и очень рекомендую начинать учиться функциональному программированию.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 03-Апр-19 16:41 
В даном вопросе я консерватор.

Исполняемая область памяти не должна изменятся, а изменяемая исполнятся.

Все что не удовлетворяет сему правилу с своей системы выкидывают!

По мере необходимости старые питоновские программы написание с ламбадами и прочими фичами функционального программирования переписываю с использованием структурного, модульного, объектного програмирования, без элементов функционального програмирования.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 03-Апр-19 22:04 
> переписываю с использованием структурного, модульного,
> объектного програмирования, без элементов функционального програмирования.

Опеннет, и ты мне говоришь, что это у меня случай клинический?! O_o

Ладно, поставим точку цитатой из одного рассказика с wasm-а, который я читал в начале нулевых:
"Да что это за программа такая, которая даже не может изменить свой собственный код?" =)


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 07-Апр-19 12:26 
Можешь писать как хочешь, констатируют лишь факт - выделения памяти в режиме WX небезопасно. Можно при этом нагородить кучу проверок, которые замедлят работу программы и всё равно не дадут гарантию безопасности.

"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 07-Апр-19 13:16 
Программа которая не изменяет исполняемую часть - удовлетворяет необходимому условию безопасности - неизменность исполняемого кода.

"В PHP 8 добавят закладку!!!"
Отправлено Аноним84701 , 04-Апр-19 12:58 

> Исполняемая область памяти не должна изменятся, а изменяемая исполнятся.
> Все что не удовлетворяет сему правилу с своей системы выкидывают!
> По мере необходимости старые питоновские программы  [...] переписываю с использованием

А почему переписывается, а не выкидывается, ведь код в интерпретаторе питона -- под RWX  (иначе тот же eval("foo") или манкипатчинг не будут работать). Непоследовательно как-то.
> без элементов функционального програмирования.

Вообще-то, функциональщина проще проверяется на корректность, особенно при поддержки автоматизмов.

> В даном вопросе я консерватор.

Не, это как-то по другому называется 🙄


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 07-Апр-19 12:32 
У меня питон с RX выделением памяти. Если программа требует выделение памяти в режиме rwx то она уничтожается. Свои мне проще переписать без lambad и они сразу начинают нормально работать.

"В PHP 8 добавят закладку!!!"
Отправлено Аноним84701 , 07-Апр-19 14:16 
> У меня питон с RX выделением памяти.

Только питонокоду, исполняемому интерпретатором СPython,  eXecute разрешения страницы до лампочки, потому что роль "CPU" в этом случае играет сам  интерпретатор.
А он прекрасно позволит добавить или изменить код с помощью eval, патчинга и еще 100500 способов:


>>> import new

# f(x) = x²
>>> def foo(x):

...     return x*x
...
>>> foo(4)

16
>>> foo(10)

100
# байткод функции
>>> foo.__code__.co_code

'|\x00\x00|\x00\x00\x18S'

# меняем опкод MUL на ADD

>>> co=foo.__code__
>>> foo.__code__ = new.code(co.co_argcount,

...                co.co_nlocals,
...                co.co_stacksize,
...                co.co_flags,
...                '|\x00\x00|\x00\x00\x17S',
...                co.co_consts,
...                co.co_names,
...                co.co_varnames,
...                co.co_filename,
...                co.co_name,
...                co.co_firstlineno,
...                co.co_lnotab)

>>> foo(4)

8
>>> foo(10)

20

# а можно было просто
>>> foo = lambda y: y+y

# любой вызов foo теперь будет выполнять совершенно другой код.
>>> foo(10)

20

Хуже того: любой ЯП, позволяющий переопределять методы/функции/процедуры во время выполнения или использовать структуры данных для реализации динамической замены (о как завернул!) методов (классический callback в си или хранилка указателя к обработчику в структуре данных -- это оно, ага) так или иначе, принципиально обходит W^X.

Но ходовые скриптовые ЯП делают это на "базовом" уровне, предоставляя атакующему не просто возможность заменить функцию-другую или поизвращаться с ROP в ASLR, а  весь мощьный, базовый набор "опкодов" интерпретатора, шикарнейшим образом вырубая рандомизацию адресного пространства, memory-guards и все "гарантии неизменности кода" (толку-то от того, что код интерпретатора не изменился, если он все равно выполнит любое нужное действие) …
Так что придется или сильно переписывать CPython или удалять, увы.
(Ba/Da/Z) sh однозначно только удалять, там слишком много завязанно на повсеместной интерпретации-выполнения ввода пользователя.


% echo "my $(time ls)"
ls -GF  0,00s user 0,00s system 68% cpu 0,006 total
my Makefile

> Свои мне проще переписать без lambad и они сразу начинают нормально работать.

Это может показаться удивительным и невероятным, но лямбды в  питоне в реализации не особо отличаются от "именных" фукции:


>>> import dis
>>> def foo(x): return x+x

...
>>> dis.dis(foo)

  3           0 LOAD_FAST                0 (x)
              3 LOAD_FAST                0 (x)
              6 BINARY_ADD          
              7 RETURN_VALUE      
  
>>> dis.dis(lambda x: x+x)

  3           0 LOAD_FAST                0 (x)
              3 LOAD_FAST                0 (x)
              6 BINARY_ADD          
              7 RETURN_VALUE        
>>> y=lambda x: x+x
>>> y.__code__.co_code

'|\x00\x00|\x00\x00\x17S'
>>> foo.__code__.co_code

'|\x00\x00|\x00\x00\x17S'
>>>



"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 07-Апр-19 16:48 
Проверю на своём питоне, в моей ОС и на моём проце.

То что такое разрешается у вас на компе не значит что можно на моём.

Результат отпишу.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 08-Апр-19 11:59 
> Проверю на своём питоне, в моей ОС и на моём проце.
> То что такое разрешается у вас на компе не значит что можно на моём.

Хоть одну причину придумай, почему на твоём это не так. Русским же языком тебе объяснили, почему интерпретаторы и языки с VM в бэке придётся выкидывать по твоей логике.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 08-Апр-19 16:46 
Да, у меня такая логика.

Заметте большую разницу с вашей логикой:

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

Я предлагаю простые алгоритмы, которые легко реализовать в железе и использовать без накладных расходов. Алгоритмы, которые дают гарантии соблюдения необходимых условий для безопасности. При этом надо всего корректно переписать пару прог...

RWX - права просты и используются изначально. Можно придумать другую ОС с другими правилами гарантирующие необходимые условия безопасности. Но это должны быть математические алгоритмы дающие гарантии!


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 08-Апр-19 18:33 
> Да, у меня такая логика.
> Заметте большую разницу с вашей логикой:
> Вы предлагает кучу сложных и затратных проверок, шаблонов и не даёте гарантий.
> Вы как майор, для которого безопасность это мозгоебство, причём чем жеще
> последнее тем они думает, что больше безопасность.

Нет. Просто твоя логика просто не обеспечивает почти никакой защиты вообще. Она ломается уже при использовании интерпретаторов.

> Я предлагаю простые алгоритмы, которые легко реализовать в железе и использовать без
> накладных расходов. Алгоритмы, которые дают гарантии соблюдения необходимых условий для
> безопасности. При этом надо всего корректно переписать пару прог...

Всего-то пару прог переписать, ага. Перепиши для начала одну JVM.



"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 09-Апр-19 15:38 
Обеспечение неизменности исполняемого кода - необходимое условие для безопасности.

Технология jit изменяет исполняемый код и по этому я её считаю небезопасной.

Не надо сотню интерпретаторов держать в системе.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 09-Апр-19 15:56 
> Обеспечение неизменности исполняемого кода - необходимое условие для безопасности.

Опять?!

> Технология jit изменяет исполняемый код и по этому я её считаю небезопасной.
> Не надо сотню интерпретаторов держать в системе.

Мда. Чукча явно не читатель.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 09-Апр-19 16:03 
Ты можешь отключить защиту памяти для любой программы:

paxctl-ng -m /path/to/program

А вся остальная система будет использовать защиту PAX.

То есть лисп и жабу без проблем запустить отключив для них защиту памяти.

Но это исключение создаст вектор атаки.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 09-Апр-19 16:45 
> Ты можешь отключить защиту памяти для любой программы:
> paxctl-ng -m /path/to/program
> А вся остальная система будет использовать защиту PAX.
> То есть лисп и жабу без проблем запустить отключив для них защиту памяти.

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

> Но это исключение создаст вектор атаки.

Бла-бла-бла. Я так тебе скажу: куда большие векторы атаки появляются из-за недостаточного срока тестирования дистрибутива, и никакие паксы тебя от этого не уберегут.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 09-Апр-19 16:49 
Я не пользовался Астрой.

Пользуясь стабильной ветвью hardened gentoo более 15 лет. Проблем нет.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 09-Апр-19 16:52 
> Я не пользовался Астрой.
> Пользуясь стабильной ветвью hardened gentoo более 15 лет.

Это типа лучше-стабильней, думаешь?


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 09-Апр-19 17:02 
Ну для сравнения можешь глянуть DYSTRYK он на фтп Яндекса есть, правда староват, 2008 года. Это почти классический hardened gentoo

"В PHP 8 добавят закладку!!!"
Отправлено freehck , 09-Апр-19 17:43 
> Ну для сравнения можешь глянуть DYSTRYK он на фтп Яндекса есть, правда
> староват, 2008 года. Это почти классический hardened gentoo

Увы, я недостаточно смышлённый, чтобы без ссылки что-либо найти в интернете. А ещё меня в Яндексе по айпи забанили.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 11-Апр-19 15:52 
https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../

Он сильно от классического Линукса отличается. Кроме усиленной безопасности реализована прозрачная для программ технология чекпоинта, - если дернуть питание и включить то все программы продолжат работать. Реализована кластерна технология единого системного образа, - прозрачно для программы ей доступно общее количество ядер и оперативы в сети (это противоположно виртуализации). Технология толстых клиентов (противоположность тонким клиентам) грузится один комп (например с ливесд) остальные грузится с него (можно без дисковые станции).


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 08-Апр-19 16:25 
Проверил на:

ядре Линукс с:

Pageexec y
Emutramp n.  #для питона рекомендуют у, но это щель
Emusigrt n
Mprotect y

Cpu intel core c NX

То есть с памятью запрещено делать:
1. Изменять статус +x если изначально память была выделена как не исполняемая.
2. Менять режим с только для чтения ro на rw.
3. Изменить статус на исполняемый анонимной области памяти.
4. Изменить RELRO добавив возможность записи +w.

Проверить new.code на 2 питоне мне не удалось. Видать плохо старался, надо функции больше параметров...

Пробовал на 3 питоне:
import code
foo.__code__=code(...)
TypeError: module object is not callable

Мене вот эта фигня досаждает:

import numpy
........
File "/usr/lib/python/site-packages/numpy/core/_internal.py", line 14, in <module>
    import ctypes
File "/usr/lib/python/ctypes/__init__.py", line 5** in <module>
    _reset_cache()
File "/usr/lib/python/ctypes/__init__.py", line 27*, in _reset_cache
    CFUNCTYPE(c_init)(lambda: None)
MemoryError

В логах:
...kernel... denied RWX mmap of <annonymouse mapping> by /usr/bin/python3

То есть сработал пункт 3 запретов деествий с памятью.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 08-Апр-19 18:36 
>[оверквотинг удален]
> File "/usr/lib/python/site-packages/numpy/core/_internal.py", line 14, in <module>
>     import ctypes
> File "/usr/lib/python/ctypes/__init__.py", line 5** in <module>
>     _reset_cache()
> File "/usr/lib/python/ctypes/__init__.py", line 27*, in _reset_cache
>     CFUNCTYPE(c_init)(lambda: None)
> MemoryError
> В логах:
> ...kernel... denied RWX mmap of <annonymouse mapping> by /usr/bin/python3
> То есть сработал пункт 3 запретов деествий с памятью.

Ну вот ты и получил ответы: WX запретить-то можешь, вот только у тебя ничего большая часть программ после этого перестаёт работать. О чём, собственно, тебе весь тред и говорили.

Добро пожаловать.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 09-Апр-19 15:57 
WX надо запретить тебе тоже использовать.

Там ошибка в 273 строке Lib/ctypes/__init__.py надо или выкинуть или if os.name in 'nt': сделать чтобы для нормальных ОС сейкод не выполнялся.

Это баг, заметь всего один, который надо отослать разрабам питона.

Сам интерпретатор у меня работает в режиме PeMRs, как и должно. У меня питон часто используется и если падает то это не корректная прога или вирь.

Попробуй использовать ОС с защитой памяти, больших трудностей не будет. Можно для лиспа с жабой защиты памяти отключить, а в место хрома использовать firefox.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 09-Апр-19 16:41 
> WX надо запретить тебе тоже использовать.

Спасибо, я предпочитаю мандатному доступу иные способы защиты.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 09-Апр-19 16:57 
Мандатной это совсем другое. Там усилий на несколько порядков больше надо.

Защита памяти PAX самое простое из всего доступного арсенала. Там фактически ничего не надо настраивать.

Следующим по сложности идёт криптографическая верификация целостности всего загружаемого.

Самое сложное - написание правил мандатного контроля доступа. Надо очень много времени, столько денег мне никто ещё не предлагал.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 09-Апр-19 17:38 
> Защита памяти PAX самое простое из всего доступного арсенала.

Да, это -- основа, и уже она задалбывает по самое некуда. Хотя не даёт ровным счётом ничего.

> Там фактически ничего не надо настраивать.

Ты никогда не портировал хотя бы среднего размера продукты под это дело? Посмотрел бы я на то, как ты будешь рассказывать сказки про "ничего не надо настраивать" после того, как перечислишь последний бинарь в 50м пакете...


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 11-Апр-19 16:01 
Именно для этого я в эту влез!

Pax даёт гарантии неизменности исполняемых на проце областей оперативно. Это необходимо для безопасности.

Pax как лампочка, включил в ядре и всё.

Проблема в том что враги ненужный вообще JIT всюда суют. Вот он pax вредит.  Jit - зло!


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 11-Апр-19 16:13 
А инные способы защиты кроме мандатного и pax какие используете, если не секрет?

Есть ещё криптографическая верификация:
Секуребут или tboot -> grub check_signatures=enforce -> Linux IMA/EVM

Мандатный я не использую из-за огромных затрат времени, но выбрал бы gradm там есть возможность автоматической генерации правил и сами правила можно человеку прочесть.

Сканирование на вири трафика и флешек самособой обязательно.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 12-Апр-19 04:20 
> А инные способы защиты кроме мандатного и pax какие используете, если не секрет?

Да не, не секрет. firewalld, docker, + иногда ipsec

Для защиты от 99.999% угроз этого достаточно. Оставшийся 0.001% реализуется только при таком немыслимом стечении обстоятельств, что тратить силы на него нет нужды, особенно при грамотной организации своевременной доставки обновлений безопасности.

Ну это если для прода, и если не вдаваться в проблемы организации многопользовательского доступа, потому что если вдаваться -- то иди говорить о безопасности с Митником, он тебе всё по полочкам растолкает. =)

> Есть ещё криптографическая верификация:
> Секуребут или tboot -> grub check_signatures=enforce -> Linux IMA/EVM

Для десктопа/ноута можешь ограничиться LUKS-ом на блочное устройство + флешка с бут-разделом.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 13-Апр-19 17:11 
Этот firewolld через dbus работает! А я dbus нафиг с системы выкидываю. Потдержываю руками скрипты с жесткой фильтрацией всего входящего и исходящего трафика на всех интерфейсах.

На щет докера и прочих контейнеров, тоже не верю. Потдерживаю свою систему создания изолированных окружений.  Старый добрый chroot + контроль привилегий линукс capabilities самым ядром с проекта grsecurity.

Vpn от настроения разные.

У меня, и у всех уже наверное /boot & / шифрования давно. MBR  не шифрованый и core.img от grub.

Загрузка с флешки мне не помогла. Есть буткиты в mbr, bios grub и руткиты в initrd. Ловил по меняющимся хешам.

Надо крыптоверификацию и вместо флешки использовать CDROM. На ROM диске не возможно изменить данные, а значит записать вирус.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 13-Апр-19 18:04 
> Этот firewolld через dbus работает! А я dbus нафиг с системы выкидываю.
> Потдержываю руками скрипты с жесткой фильтрацией всего входящего и исходящего трафика
> на всех интерфейсах.

Свои скрипты? Ну это безусловно можно, а чем iptables-persistent не подошёл?

> На щет докера и прочих контейнеров, тоже не верю. Потдерживаю свою систему
> создания изолированных окружений.  Старый добрый chroot + контроль привилегий линукс
> capabilities самым ядром с проекта grsecurity.

Я тоже не верю, но лишним не будет.

К тому же, с ним деплой облегчается в разы. А если надо оркестровку сервисов на нескольких машинах, то объединить его в k8s -- и всё вообще великолепно работает. Если инфра небольшая, то вместо k8s можно и вовсе руками водрузить docker+etcd+flannel/calico.

> Vpn от настроения разные.

Согласен, тут всё зависит от цели. Если пользователей пускать во внутреннюю сеть, то хватит и openvpn. Ежели же надо объединить пару сетей, если между ними трафика много или они удалены друг от друга, или нужно просто это прозрачно сделать -- ну тогда ipsec, может l2tp ещё.

> У меня, и у всех уже наверное /boot & / шифрования давно. MBR  не шифрованый и core.img от grub.
> Загрузка с флешки мне не помогла. Есть буткиты в mbr, bios grub и руткиты в initrd. Ловил по меняющимся хешам.

Это уже интереснее. Я бы послушал подробности.

Руткит в initrd -- ну это ты сам себе злобный буратино. Я с этой флешкой не расстаюсь никогда.

По поводу bios grub... Так это, разве компы с bios boot partition ещё существуют?

Про bootkit в mbr -- ну тут уже бабушка надвое сказала. Можно визуально сделать два слегка различных загрузчика на диске и флешке.

А вообще, проблемы-то на этом не заканчиваются. Если тебя захотят сломать, могут и хардварный килоггер в клаву запихнуть. Так что на самом деле защита тут не бывает 100%й, разве что ты никогда не расстаёшься со своим ноутбуком.

> Надо крыптоверификацию и вместо флешки использовать CDROM. На ROM диске не возможно
> изменить данные, а значит записать вирус.

Можно, но диск легче расфигачить, нежели флешку. Обидно будет, если ты в поездке споткнулся, и диск вдребезги. Другое дело, этот минус -- он же плюс. Если надо избавиться от диска -- взял да и кокнул. С флешкой так легко не получится.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 14-Апр-19 10:16 
У меня скрипты iptables тянутся с 2000г., а ipfw с 2010г. Все вылизано руками. Cобираюсь переписать iptables на nftables.
Автогенераторы фаерволов не использовал. Писал свои правила на основе модуля recent и ipset для автоматической реакции сетевого экрана на атаки. Сами правила сетевого экрана изменятся не должны, иначе есть вероятность что вирь дыру для своих друзей откроет.

В РФ есть опасный баг в подготовке специалистов по ИТ безопасности - не различают софт разработанный для удобства администрирования и софт для обеспечения безопасности. Докер это первое нет в нём гарантий изоляции. У меня скрипт, грубо говоря 10 строк на баше, создаёт/обновляет контейнер. И ещё один который обновляет все контейнеры в системе ещё на 10 строк. Обновил систему, поменял настройки, дёрнул скрипт и всё контейнеры свежие. Хочешь  с консоли, по ssh или своей оркестровкой дергай. Hardeneed chroot даёт довольно сильные и очень дешовые гарантии изоляции.

Компы с биосом ещё есть. /boot & / шифрованы. Grub core.img с крыптографией для расшифровки /boot и публичным ключом для проверки цифровых подписей себя, kernel & initrd (где есть крыптография для расшифровки / и публичные ключи для IMA/EVM) устанавливается перед первым разделом за MBR, или если места там не хватает то в отдельный раздел BIOS grub. Атака на core.img даст возможность получить доступ  к шифрованому /boot и ключу проверки подписей всего что в /boot... и так далее по цепочке загрузки. Это можно сделать удаленно. Чем раньше буткиты получает доступ в процессе загрузки тем больше у него возможностей для своего скрытия.

Флешку можно изменить, аппаратный перекльчатель флешки в режим только чтения сегодня редкость. CD-ROM гарантия неизменности данных. Но и с этим проблемы, мне сменили прошивка CD/DVD привода! Теперь приводы оптических дисков во время работы отключают.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним84701 , 13-Апр-19 19:50 
> Надо крыптоверификацию и вместо флешки использовать CDROM. На ROM диске не возможно  изменить данные, а значит записать вирус.

На самом деле никому оно толком не нужно:
Был такой проект еще (почти - лень смотреть точную дату) 10 лет назад, antibootkit назывался.
"По мотивам" нашумевшего тогда буткита Клейснера, который, типа "расшифровал трукрипту" (на самом деле в загрузчик TC встраивался кейлогер).
Простенький (т.е. вполне верифицируемый глазками) загрузчик где-то на тысячу строк fasm,
(плюс "ассистент" на Си, который вообще заменяется скриптиком c вызовом dd), без каких-либо зависимостей.

Умел считать sha1-хеши первых секторов дисков, сравнивать их с вшитыми в загрузчик[т.е. самого себя] (или просто показывать, чтобы можно было записать и потом "вшить" ассистентом в загрузчик-ISOшку, без пересборки), выдавать предупреждение в случае расхождения хешей или автоматически переключаться на дефолтный системный загрузчик в ином случае.

Там принципиально только 3 дыры:
Загрузчик должен быть на ROM (иначе, соотв. модифицируются проверочные хэши).
Хардварный кейлоггер/перепрошивка биос или фирмвари.
И  можно "фейкнуть" скрин загрузчика - т.е. буткит показывает точно такой же скрин.
Правда, просто показать мало - нужно еще модифицировать порядок загрузки (или как-то незаметно предотвратить загрузку с носителя), ну и можно выводить в скрине загрузчика какое нибудь дополнительное "кодовое" слово, прошиваемое вместе с хешем (слово, в отличие от хеша, нельзя будет посчитать из имеющейся информации).


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 14-Апр-19 12:50 
Думал в этом же направлении.

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

Сам grub довольно продвинутый он имеет: cmosdump, lspci, usb, sha*sum & if then else. Мне не хватает | чтобы в подписанном цифровой подписью grub.cfg верифицировать неизменность железа и cmos биоса. С dd можно было бы и MBR верифицировать.

Слышал есть загрузчики заточены на криптоверификацию железа, биоса, бута на диске?

Сам никогда не работал в отделе ИТ безопасности. И с годами замечаю что все больше времени трачу именно на безопасность. Постепенно превращаясь в того мозгоебщика, что пристает и кричит не использовать jit, docker, сетевые экраны что сами себя пишут и как им захочется во время работы модифицируют себя. Не в ту сторону этот мир свернул...


"В PHP 8 добавят закладку!!!"
Отправлено Аноним84701 , 08-Апр-19 20:18 
> То есть с памятью запрещено делать:
> 1. Изменять статус +x если изначально память была выделена как не исполняемая.
> 2. Менять режим с только для чтения ro на rw.
> 3. Изменить статус на исполняемый анонимной области памяти.
> 4. Изменить RELRO добавив возможность записи +w.

Интерпретатору  (тому который, внимание ирония: без JIT)  это до одного места (в ином случае, помимо кучи модулей и библиотек, тот же REPL питона или интерактивный шелл не будут работать, т.к. там основное действие - читать и исполнять ввод пользователя):


# part of a bigger script
# ...
# this is our simple log script, we log all logins. Nothing can go wrong, we have no RWX, no +x … trust me, I know what I'm doing!
echo "$(date): Bad guy tried to log in and steal your pr0n with invalid username: $USER, action: access denied" > important.log
# ...

и

% # simulate bad guy login
USER="$(rm -rf ~/*)"; echo "$(date): $USER tried to log in and watch pr0n, access denied > importantlog.log

код интерпретатора (*sh) остался неизменным. Правда пользователю от этого вряд ли сильно легче.


> Проверить new.code на 2 питоне мне не удалось. Видать плохо старался, надо функции больше параметров...

Наверное у Вас Особый Питон, не такой как у всех остальных, без возможности переопределения методов, eval, exec, import - *завидует* (угу, вот щаз прям побегу полноценный, красивый и гладкий PoC писать … сразу после глажки шнурков)

> Пробовал на 3 питоне:
> import code
> foo.__code__=code(...)
> TypeError: module object is not callable

Если вы считаете, что это не работает из-за режима W^X, то у меня для вас плохие новости: вызов модуля не работает вообще у всех (это такое ограничение ЯП).
В тройке это делается так:


>>> import os
>>> def foo(): print(1+1)

...
>>> foo.__code__ = compile("print(os.listdir('/'))",'<string>','single')
>>> foo()

[ 'usr', 'dev', 'mnt', 'tmp'


или с code

import code, os
def foo(): print(1+1)
foo()
2
x=code.compile_command("import os;print(os.listdir('/'))")
foo.__code__ = x
foo()
[ 'usr', 'dev', 'mnt'

> Мене вот эта фигня досаждает:
> import numpy
> ........
> File "/usr/lib/python/site-packages/numpy/core/_internal.py", line 14, in <module>
>  import ctypes
> То есть сработал пункт 3 запретов деествий с памятью.

Угу, срабатывание при попытке загрузки сишной либы питоном  через жо^W  "универсальным" для кучи ОС методом (интересующиеся могут глянуть в ctypes.__init__) все расставило на свои места.
Правда, можно просто записать любую либу и подгризить ее штатными методом (это не будет ANONYMOUS_MAP), но пссст, это тайное знание.

Ну и подгружать и выполнять свежую, измененную библиотеку питона из питона - можно хоть каждую секунду.


% cat load.py  &&  echo "print(1+2)">mylib.py && python3 load.py&
import time,imp,mylib
while True:
    try:
        imp.reload(mylib)
    except Exception as ex:
        print(ex)
    except:
        pass
    time.sleep(3)
3
3
3
% echo "import os;print(os.listdir())" > mylib.py
[ 'serv.py', 'clipnotify',

% echo "import runpy;print('0wn3d');runpy.run_module('http.server',run_name='__main__')" > mylib.py
0wn3d
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
127.0.0.1 - - [08/Apr/2019 18:59:04] "GET / HTTP/1.1" 200 -


Увы.

"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 09-Апр-19 16:45 
Там в Lib/ctypes/__init__.py агентура мелкомягких в 273 строке баг засунула ее выкинуть надо.

Обычный пользователь, на запись имеет доступ только в свой домашний каталог и свои временные файлы, а важные системные настройки не может даже читать. Хорошо, если в систему имеет доступ может свои файлы похерить. Стоит использовать разных пользователей для работы и посиделок на оперение... Или еще лучше разные девайсы. И не держать ненужные интерпретаторы.
Под рутом можно похерить много /home /var где смонтировано rw.

Давайте подведем итог.

Jit - зло для безопасности.

Интеипретатор, если не изменяет свой код во время работы и вообще корректно работает с памятью хорош. Написание программы на таком интерпретаторе хорошо. Она самим интерпретатором проверяется на корректность, а ядро присматривает за работой интерпретатора с памятью. Мы следим за целостностью и гарантируем неизменность интерпретатора во время его работы - это необходимо для безопасности.

Если интерпретатор или любая прога изменяет исполняемую область памяти я не знаю как гарантировать неизменность исполняемой программы. Просто констатирует,что на проце выполняется не то что загрузили с диска. Это создаёт проблему  для безопасности.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 09-Апр-19 16:49 
> Давайте подведем итог.

И заключается он, увы, в плохом понимании реальных проблем безопасности людьми, ратующими за pax.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 09-Апр-19 17:10 
Есть много необходимых техник безопасности. Я здесь затрагивал только одну, pax. И говорил что он с jit совсемине не дружит. Если вы программы напишите с jit это исправить будет очень сложно!!!

Другие техники безопасности pax дополняют.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 09-Апр-19 17:49 
Ладно. Парень, я вот что думаю -- это очень показательный диалог. Будешь устраиваться на работу, обязательно покажи его интервьюеру! )))

"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 11-Апр-19 16:55 
Мне будет стыдно за твои ответы.

И работодатель увидеть что я на пустые разговоры время трачю. Говориш людям, - "jit - зло", ибо с ним невозможно дать гарантии неизменности исполняемого кода, необходимы для безопасности. А они сказки о сложности "настройки" pax рассказывают.


"В PHP 8 добавят закладку!!!"
Отправлено freehck , 12-Апр-19 04:06 
> Мне будет стыдно за твои ответы.

Ничего страшного. Я даю разрешение их показывать и высмеивать. Правда-правда, ссылайся на этот тред. Это будет верное решение, далеко пойдёшь, уверяю тебя! )

> И работодатель увидеть что я на пустые разговоры время трачю. Говориш людям,
> - "jit - зло", ибо с ним невозможно дать гарантии неизменности
> исполняемого кода, необходимы для безопасности. А они сказки о сложности "настройки"
> pax рассказывают.

Ну тебе-то виднее, что я написал. Куда уж мне себя понять. Со стороны-то всё чётче и яснее. =)


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 13-Апр-19 17:24 
Ссучились сегодня крупные работодатели. Мелкие нужного мне заплатить не смогут.

Писать что-то вредное - религия не позволяет.

Те проекты что создал в следствие изменения законов РФ внедрять здесь рискованно. Надо много тратить времени на разбор постоянно меняющихся законов.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним84701 , 09-Апр-19 17:16 
> Если интерпретатор или любая прога изменяет исполняемую область памяти я не знаю
> как гарантировать неизменность исполняемой программы. Просто констатирует,что на проце
> выполняется не то что загрузили с диска. Это создаёт проблему  для безопасности.

Только вот ROP (которому все равно для запуска нужны, плюс-минус, те же условия, что и "классическому", адресонезависимому, инжектнутому  машкоду и который [уязвимость к ROP] вообще-то уже 10 лет назад собирались выпилить: https://www.csc2.ncsu.edu/faculty/xjiang4/pubs/EUROSYS10.pdf, но не судьба[1]) не требует изменять исполняемую область памяти, позволяя атакующему выполнять свой код в обход.
Поэтому гарантии неизменности кода могут быть только при полном отсутствии разешения на запись вообще, для всех страниц.


____________
[1]Видимо, потому что тогда придется заменять не только RET, но и все разновидности вида "POP REG, JMP REG == последовательности в 3 байта для x86", которых в достаточно большом бинарнике-библиотеке достаточно.

Самое смешное - достаточно было бы отказаться от самой возможности смешивания обычных данных и адресов возврата, чтобы закрыть эту дырищу без оверхеда.

ЗЫ: На десктопе/ноуте все равно нужно будет внести самую главную дыру современности -- браузер, в исключения [из PaX].
И толку тогда, мудохаться с исключениями и подстройкой правил (а они могут быть  неочевидными, например работа граф. пайплайна для игрушек, эмуляторов и прочего - когда я последний раз тыкал это дело, тот же  konsole из КДЕ не запускался) …


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 11-Апр-19 16:47 
Интерпретаторы можно все рубануть спомощью chmod & chown. Завести двух юзеров, одного для работы другого для инета. Тому что для инета интерпретаторы не давать, kde5 без них работает. Это очень дёшево по сравнению с мандатным методом.

Вот от поднятия юзером своего сервера, бекдора, я в своей текущей конфигурации дешового метода защиты не нашел grkernsec_socket_server=y рубает клаву с мышкой, надо много пересобирать будет в десктопе.

Если бровзером не оспользуется qtwebengine то снимать защиту памяти не надо, такие бровзеры есть.

PAX_RAP=y даёт защиту от атак "использующих куски кода". К сему атака с повторным использованием кода на много порядков сложнее и дороже чем классическое переполнение буфера.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним84701 , 04-Апр-19 12:49 
> JIT - нарушает главное правило построения безопасной ОС.

А пацаны в опенбсде и не знали, продавливая патч для корректного взаимодействия JIT с W^X в Firefox:
https://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in.../
> When we need to patch JIT-code for some reason, we use a RAII-class, AutoWritableJitCode, to make the page(s) we're
> interested in writable (RW), using VirtualProtect on Windows and mprotect on other platforms. The destructor then
> toggles this back from RW to RX when we're done with it.

.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 07-Апр-19 12:54 
Надо смотреть патч.

У меня понятие корректности может не совпадали с вашим или их!

Мое понятие корректного обрабатывания попытки выделения памяти в режиме rwx программой:
Программа должна разветвляется на две части после проверки возможности выделения памяти в режиме wx. Если ОС или процом выделение памяти в режиме wx запрещено - выполняется код использующий только выделение памяти в режиме rx, если такого запрета нет, то используется ветвь кода выделяющая память в режиме rwx.

Классическим,эталонным примером можно рассмотреть clamav. Там это ветвление сделано правильно.

Я призываю выделять память для исполняемых программ - rx, для изменяемых данных rw. У меня, дистр основан на исходниках и всё оптимизируется под мой проц при компиляции, оптимизация во время исполнения программы мне не нужна. Меня наоборот больше интересует гарантия неизменности выполняемого кода как необходимое условие безопасности.


"В PHP 8 добавят закладку!!!"
Отправлено Аноним84701 , 07-Апр-19 13:46 
> Надо смотреть патч.
> У меня понятие корректности может не совпадали с вашим или их!
> Мое понятие корректного обрабатывания попытки выделения памяти в режиме rwx программой:  
> Программа должна разветвляется на две части после проверки возможности выделения памяти
> в режиме wx. Если ОС или процом выделение памяти в режиме
> wx запрещено - выполняется код использующий только выделение памяти в режиме
> rx, если такого запрета нет, то используется ветвь кода выделяющая память в режиме rwx.

Достаточно было просто пройти по ссылке или прочитать цитату -- память там _никогда_ не находится в режиме RWX. RW при генерации кода (или изменении) JIT-ом, переключаемое перед выполнением в RX.  


"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 07-Апр-19 16:43 
Это плохо, должно быть ветвление на два кода, с jit, и без.

"В PHP 8 добавят закладку!!!"
Отправлено Аноним , 07-Апр-19 17:06 
Переключение памяти с одного режима в другой на нормальных системах запрещено. Программа просто убьётся ядром при попытке сделать такой грех.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Вася , 31-Мрт-19 13:01 
Круто, теперь точно пересяду на PHP с Golang

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:31 
Говори правду ВЕРНЕШЬСЯ а не пересядешь, нечего тут народ в заблуждение вводить.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:05 
Есть же rust зачем php?

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:22 
> Есть же rust зачем php?

Где ж вы были 20 лет назад, когда php только создавался?


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:34 
Похапэ прост, на нём может писать и обезьяна, в то время как даже обладатели IQ=180 никак не могут написать ничего полезного на расте.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 18:50 
Похапэ давно не прост, наоборот переусложнен.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 20:06 
Просто на нём программируют те кто не осили ворд. Для них всё будет переусложненным.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 05:01 
Сильное заявление, проверять его я конечно не буду

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Попугай Кеша , 01-Апр-19 11:44 
Для обезьян работы много. Кто-то ее же должен делать, правильно? Вы же с православной Java не перейдете и не будете делать работу мартышек? Нет? Ну и не вякайте

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено th3m3 , 31-Мрт-19 16:05 
Для неосиляторов.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Ilya Indigo , 31-Мрт-19 13:10 
Тот редкий случай, когда об этом узнаёшь за долго до новостей. :-)

P.S. В 7.3 включение jit для pcre2 по умолчанию пошло боком, по крайней мере для unix-like систем. Судя по удивлённым комментам разрабам на оффтопике не проявляется.
https://bugs.php.net/bug.php?id=77260
И чего-то они даже не чешутся это не то что исправить, а даже подтвердить!

Надеюсь в 8-ке jit для всего будет работать лучше и не только на оффтопике!


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:23 
> https://bugs.php.net/bug.php?id=77260

ркн официально запретил рашичам переходить на этот сайт.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:30 
Даже они понимают что пых зло.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Ilya Indigo , 31-Мрт-19 13:32 
Ё-маё, действительно РКН оборзел.
У меня с автопроксёй работает https://antizapret.prostovpn.org/proxy.pac
Удивительно, что его туда добавил,список сделан для захода на треккеры.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено myhand , 31-Мрт-19 13:51 
Это вы оборзели проксями пользоваться.

Вам же ясно сказали: распространение данной информации нарушает закон Российской Федерации.  Может фигурные скобочки в PHP служат пропагандой гейства, подозрительны они.

Ничего, скоро прокси прикроют - Роскомнадзор уж всем письма счастья разослал и чуть менее чем все его послали.  Будете проксей касперского пользоваться, которая берет под козырек тов. майору.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 14:57 
Поговаривают что террористы используют пхп. Зато раст террористы пока не осилили.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено myhand , 31-Мрт-19 15:22 
И всегда останется whitespace.  Учитывая новейший закон "об уважении власти" - обыватели скоро не только программировать на нем начнут, но и обычные мысли выражать...  Так победимъ!

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 16:01 
Спорим, что ты его даже не открывал, но уже составил мнение. Зачем думать самому, тебе же всё прожевали и объяснили неполживые "лидеры мнений".

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено myhand , 31-Мрт-19 16:21 
> Спорим, что ты его даже не открывал, но уже составил мнение.

И что я у вас выиграл в результате спора?

> Зачем думать самому...

Вы уверены, что вам вообще кто-то это способен объяснить?


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Ключевский , 01-Апр-19 02:25 
Это они за телеграмом гонялись

Блокировка по ip:
Подсеть: 206.189.0.0/16
Гос. орган: Генпрокуратура
Постановление: 27-31-2018/Ид2971-18

По этому постановлению телеграм мочат


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Брат Анон , 02-Апр-19 08:23 
Вот если бы сайт был в такой форме -- точно бы запретили:

(.)(.)
)  (
(  . )


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 15:58 
Мегафон - заходит. Ркн ни при чем. А если у вас не работает - пишите жалобы, а не стоните в интернетах.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 16:00 
Гонщик. Очень даже при чём. IP bugs.php.net в блоклисте.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 16:06 
С Мегафон Поволжье заходит. Проверяйте или меняйте провайдера.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 16:11 
> С Мегафон Поволжье заходит. Проверяйте или меняйте провайдера.

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

Билайн ярославль (и мобильный, и домашний интернет), не заходит.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:00 
Надо на ваш мегафон РКН'у настучать :D

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено пох , 31-Мрт-19 17:49 
> Мегафон - заходит. Ркн ни при чем.

так вы напишите им жалобу, что гуанофон-поволжье плохо защищает вас от вражеского интернета - и РКН тут же сделает им "причем".

на нас один клиент написал - на следующий же день к нам пришли нифига не с миром. И навещали после этого раз в пол-года, на регулярной основе - видимо, товарищ-майор взял на карандаш.

с тех пор мы _очень_ старательно защищали их от интернета. Ну если вместе с интернетом - так мы же не виноваты, что сверху пришло,то и воплотили. За два года, что я имел к этому отношение - клиент, между прочим, никуда не сбежал. Видимо, был вполне доволен.

P.S. Калининград, если кому вдруг интересно, где подобные м.. обитают. Впрочем, подозреваю, они обитают повсеместно, нам просто неповезло именно там.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 20:08 
Я бы на их месте виндузятников просто в интернет не выпускал. А они только раз в год полгода к вам приходят. Капец у вас там лайтово.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Ключевский , 01-Апр-19 02:26 
Блокировка по ip:
Подсеть: 206.189.0.0/16
Гос. орган: Генпрокуратура
Постановление: 27-31-2018/Ид2971-18

Надо на твой мегафон писать жалобу, они не выполняют блокировку


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 07:19 
Владивосток, ростелеком - зашёл без проблем...
Может у вас блок лист протухший? Или индивидуальный для Вас? :)))

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 08:07 
О, целая перепись потенциальных штрафодателей :D

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 09:51 
Вы смеётесь, а какой-нибудь клоун сейчас реально пойдёт и жалобу напишет :(

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 19:13 
Так это проблема не в нём вовсе, а в наличии самих "блокировок".

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено нах , 18-Апр-19 14:52 
"но кто же тогда написал четыре миллиона доносов?!"


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено hiveliberty , 01-Апр-19 10:07 
Тоже Ростелеком и тоже открывает. Поволжье.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Анонимс , 31-Мрт-19 16:28 
> В 7.3 включение jit для pcre2 по умолчанию пошло боком, по крайней мере для unix-like систем. Судя по удивлённым комментам разрабам на оффтопике не проявляется.
> https://bugs.php.net/bug.php?id=77260
> И чего-то они даже не чешутся это не то что исправить, а даже подтвердить!

И как это понимать? Засланные казачки из Микрософта? Может это начало по захвату PHP? Не удивлюсь, если следующая новость будет "Микрософт покупает PHP и дропает поддержку Unix-like систем".


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Ilya Indigo , 31-Мрт-19 16:39 
> И как это понимать?...

понимать != фантазировать

1 Разрабы пишут и тестят под оффтопиком.
2 jit, на данный момент, сырой.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено MS , 18-Апр-19 14:53 
мы такого мусора - не покупатели. Обратитесь в орацле, может они купят.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Rodegast , 31-Мрт-19 13:28 
А юникод они уже добавили?

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:32 
В пейтоне три это кроме тормозов ничего не дало.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 01:58 
Это миф тех кто программировать не умеет.
Используйте себе тип bytes или bytearray и будет у Вас производительность уровня Python 2.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Ilya Indigo , 31-Мрт-19 13:35 
Через mb_string давно!
Делать по умолчанию для всего они и не планируют.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:48 
Больше префиксных костылей - богу костылей!

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено пох , 31-Мрт-19 17:50 
фанаты гов...юникода - должны страдать.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 08:33 
Saahriktu, перелогинься.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:50 
В Perl, Python, Go, Ruby, Java, C♯ есть из коробки.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 14:45 
Еще в erlang и elixir например.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 15:43 
Только это всё не нужно, поскольку есть Rust с самым быстрым и безопасным юникодом.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 01:59 
😀

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 20:25 
Доооо...

Erlang/OTP 21 [erts-10.3] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1]
Eshell V10.3  (abort with ^G)
1> CyrChars = <<"АБВ">>.
<<16,17,18>>
2> CyrChars1 = <<"АБВ"/utf8>>.
<<208,144,208,145,208,146>>

Уж извини, но в первом случае интерпретатор должен был либо ругнуться из-за отсутствия модификатора типа /utf8, либо проглотить данную строку как есть. А молча преобразовать во что-то другое, не то, что было ему передано - это как раз поведение, характерное для сабжа, приводящее к false=true, за которое оный был многократно руган всеми, кому не лень.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 13:47 
> является ввод/вывод

Так могут мыслить только ретрограды из лагеря ПХП.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 15:02 
Просто посмотрели на характер применения. И в них так то ввод вывод и есть узкое место.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 15:31 
Оно могло бы и не быть узким местом, если пересмотреть архитектуру PHP фреймворков.
А так да, 1С обязан тормозить.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:03 
Именно так. Наплодят "классической" обёртки в 100500 классов с инициализацией и столько же файлов на каждый запрос под язык с динамической сборкой, а потом удивляются - а чего это всё так тормозит.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено anonymous , 31-Мрт-19 14:28 
Интересно а как он будет работать ?
Вот к примеру html с кучей кусков php кода ... хм.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 15:00 
Новость почитай он будет выполнять так же медленно как и раньше.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено anonymous , 31-Мрт-19 16:01 
Причем тут медленно или быстрее ?

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


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Евгений , 31-Мрт-19 17:13 
PHP, по определению, просто язык программирования, какая разница как он расшифровывался когда-то.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 20:10 
Никак.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено anonymous , 31-Мрт-19 20:57 
В этом то и соль. Жаль не все ЭТО понимают :(

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:13 
Превратить куски HTML в 'echo(...)' - это такая проблема, дооооо.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:04 
Если файл не изменился - зачем его заново компилировать?

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Крикет , 01-Апр-19 08:03 
Да вы 3а-ебали уже всех со своей конпеляцией. Ничего 7-ой не конпелирует если в коде нет изменений. Opcahe он хранит для единожды сконпелированых скриптов.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 15:11 
Зачем юникод _в ядре_?
Стандартная библиотека поддерживает юникод со времён PHP 4, никаких абсолютно никаких проблем при работе с юникодом несмотря на то, что в ядре его нет.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено пох , 31-Мрт-19 17:52 
> Зачем юникод _в ядре_?

чтоб тормозило, и для подсчета длины строки - обязательно надо было знать, какими именно символами она набрана.

> никаких абсолютно никаких проблем при работе с юникодом

это у вас их нет, а больные фанатики привыкли страдать, им неудобно.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 15:27 
>так как даёт возможность вывести PHP за рамки web-разработки

Лучше не надо ...


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Remote_Code_Execution , 31-Мрт-19 15:35 
Оно и так уже делает при помощи phar и сериализации больше чем дозволено.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено пох , 31-Мрт-19 17:54 
с разморозочкой - кто не видел системы управления виртуальными машинами (не гуй, а _управления_) на пехепе - тот лох и неудачник.
2008й год, если что. (ну, в смысле, тогда уже точно было, а раньше я не знаю, я там не работал)

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено хотел спросить , 31-Мрт-19 15:49 
PHP не нужен, PHP мертв. Нужно быть дятлом, чтобы на нем начинать новый проект.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 15:52 
Я это блеяние слышу уже где-то лет 10. А PHP и ныне там, и доля в Web у него всё так же запредельная (до де факто безальтернативности), без каких-либо существенных изменений.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено пох , 31-Мрт-19 17:56 
> Я это блеяние слышу уже где-то лет 10

Мала-аа-адой чилавек, паспорт предъявите, а то мы вам сигареты нипрададим!

десять лет он слышит... я этот бред в 2000м уже слышал. Пехепе был поди, 4 еще?


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 20:12 
Особенно смачно отмачили те кто перешел с пхп на перл.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено rex , 05-Апр-19 19:28 
> перешел с пхп на перл

и правильно сделали, до 5.? пхп был плохо юзабелен;
а потом выбор для дальнейшего перехода стал еще шире


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:06 
Плин, ты просто не представляешь, как ты попал в точку... до сих пор так и спрашивают. Скоро 4 десяток пойдёт, да и морда шириной явно не подростковая, и тем не менее.

Я с 4 начинал, 3 мимо меня прошёл. Но вопли как-то усилились с появлением всяких пыхтонов и рубей, впрочем, за те же 10 лет понятно, что вопли так воплями и остались.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:07 
// 5 десяток, не 4, они ж с нуля... :D

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено myhand , 31-Мрт-19 23:43 
> Я с 4 начинал, 3 мимо меня прошёл. Но вопли как-то усилились
> с появлением всяких пыхтонов и рубей

Походу мимо вас прошло и то, что питоны всякие появились лет на пять раньше этого вашего пыхпыха.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 02:05 
Разрешите вставить ;)

Стоимость PHP на рынке минимальна. Берут школьников без образования.
Результат виден сразу. Умничают мало. Сайты работают. Что еще надо?

Уровень российского ретейла это полностью удовлетворяет, а остальные
две с половиной компании используют Java или .NET.

Относительно Python, Golang, Rust и т.д. пока Вы не стали руководителем,
то скоере всего в компании будет именно главенствовать какой-то PHP или
что-то примитивное и всем понятное.

Опять таки до определенного момента конечно ...
Момента уровня аудитории VK или Facebook, то есть для некоторых компаний никогда.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Ононем , 01-Апр-19 04:22 
В петоне школьники с образованием косячат почище пыхеров, но с умным видом, образование же.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено пох , 01-Апр-19 07:01 
> Относительно Python, Golang, Rust и т.д. пока Вы не стали руководителем,
> то скоере всего в компании будет именно главенствовать какой-то PHP или

я работаю в компании, где после появления руководителей у отдела разработки (до этого они напрямую подчинялись слишком высоким для вникания в детали начальникам) пихон выпихнули, наняли десяток пхп-кодеров, а разработчики на пихоне пошли на мороз.

И так будет с каждым!


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено YetAnotherOnanym , 01-Апр-19 12:12 
Так вот кто снабжает кадрами стартапы, работающие по принципу "ща пабыринькому на питоне концепт накарябаем, выкинем в продакшон, чтобы маркетшаре отхавать, а потом привлечём инвестиции, да как сядем, да как перепишем на быстрых сях, да как потекут деньги рекой, так что огого".

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено пох , 02-Апр-19 20:11 
> Так вот кто снабжает кадрами стартапы, работающие по принципу "ща пабыринькому на
> питоне концепт накарябаем, выкинем в продакшон, чтобы маркетшаре отхавать, а потом

вряд ли - такой кадр туда не пойдет, у него ентерпрайс, "знание бизнес-логики", умение на лету схватывать тонкие цветовые отличия красного от оранжевого и правильно выбирать цвет штанов, и никакого тебе agile,scrum,владение slack на уровне эксперта, требуемого в этих стартапах.

скорее они из такого сюда пришли, а вот куда ушли - лучше не знать.

> привлечём инвестиции, да как сядем, да как перепишем на быстрых сях,

на быстрых objective-сях они не перепишут, они напишут "приложение для iOS, а пользователям ведроида потерпеть еще несколько месяцев" (уровень маркетинга - Бох!). А внутри конторы так и будет все на пихоне и на бумажке - пользоватеи с ипхонами этого не видят, их это не огорчит.



"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 08:10 
Они дальше своего террариума не вылезали, поэтому как-то фиолетово. Да и сейчас фиолетово. Если те же пыхтоны в скриптах управления допустим в CentOS/RHEL заменятся в каком-то разрезе времени на пых, будет очень приятно.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Попугай Кеша , 01-Апр-19 11:45 
Смотря какой проект. Если сделал лендинг, передал распальцованному дяде за 10 тыщ рублей на бесплатном или околобесплатном шаред-хостинге - то ок.

Если что-то на долгосрок - тогда я бы поспорил. Взять хотя бы JS/Node.JS.

Для себя - на чем хотите, на том и разрабатывайте. ИМХО рынок труда диктует


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено хотел спросить , 05-Апр-19 12:38 
> Смотря какой проект. Если сделал лендинг, передал распальцованному дяде за 10 тыщ
> рублей на бесплатном или околобесплатном шаред-хостинге - то ок.
> Если что-то на долгосрок - тогда я бы поспорил. Взять хотя бы
> JS/Node.JS.
> Для себя - на чем хотите, на том и разрабатывайте. ИМХО рынок
> труда диктует

JS? на долгий срок? мда

IT как оно есть.. во всей красе.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 15:52 
Отлично. Наличие JIT окончательно переведёт PHP в разряд языков общего назначения.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено пох , 31-Мрт-19 17:56 
как будто сейчас что-то вам мешает...

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено myhand , 31-Мрт-19 18:54 
Засмеют.  Же.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:09 
Да не, у меня все системы управления на нём. Но JIT'а с кэшем такового не хватает конечно. С JIT'ом на нём уже можно будет делать серьёзную обработку данных...

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено хотел спросить , 05-Апр-19 12:38 
> Да не, у меня все системы управления на нём. Но JIT'а с
> кэшем такового не хватает конечно. С JIT'ом на нём уже можно
> будет делать серьёзную обработку данных...

в хендлерах веб-страниц? )))


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 31-Мрт-19 16:07 
> возможность вывести PHP за рамки web-разработки, благодаря повышению производительности при выполнении таких задач как машинное обучение, математические расчёты, анализ данных, 2D- и 3D-рендеринг

Чтоб вам всю жизнь на похапе писать!


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:10 
При маркешейре в 90% в вебне и потенциале выхода в лист ЯПОН - неплохая так перспектива, с него кормиться можно.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Tita_M , 31-Мрт-19 17:10 
>кардинального роста производительности для web-разработчиков не предвидится, так как основным узким местом для большей части применяемых на сайтах PHP-скриптов является ввод/вывод (обработка сетевых соединений, чтение и запись файлов, обращение к СУБД, кэширование и т.п.), а не скорость выполнения на CPU.

А как быть с фэйсбуком и вконтакте, которые какими-то своими костылями ускоряли PHP?


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Евгений , 31-Мрт-19 17:14 
Они не костылями ускоряли, а писали свои реализации (интерпретаторы). HHVM, упомянутый в статье, как раз интерпретатор и диалект PHP от фейсбука.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Tita_M , 31-Мрт-19 17:24 
Так получается, что только после HHVM узким местом в PHP стал уже ввод/вывод, а не выполнение на CPU?

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено agent_007 , 01-Апр-19 12:44 
> Так получается, что только после HHVM узким местом в PHP стал уже ввод/вывод, а не выполнение на CPU?

Нет. В том, что пишут на php узкое место почти всегда ввод-вывод.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:11 
Фейсбуком. Они это подхватят, они ж как раз эту идею с JIT первыми и толкали.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено microcoder , 31-Мрт-19 17:22 
Интересно, они хотят Python потеснить, создать конкуренцию в его нише? Это отличная новость. Python не заржавеет тогда, будет подтягиваться и развиваться.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено A.Stahl , 31-Мрт-19 17:29 
Или сдохнет, что тоже неплохо.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено myhand , 31-Мрт-19 17:40 
Julia уже "закопала" питон, ага.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено пох , 31-Мрт-19 17:57 
поздно - половина hg уже переписана на хруст :-(

лучше бы уж, право, на пехепе.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:15 
Всё может случиться. Прелесть пыха в сравнении с пыхтоном в том, что он тянет с собой годами отлаженные библиотеки на нативных сях с минимальной обёрткой, а не использует велосипеды на себе самом вместо них.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено myhand , 31-Мрт-19 23:43 
Рукалицо.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено аноним3 , 01-Апр-19 02:09 
а мат расчеты и все эти массивы и матрицы тоже на пыхе? я бы посмотрел конечно как это в расчетах и написании. та прога что на питоне пишется за вечер и на 1 листе в максимум 50-60 строк на пыхе растянется в поэму лермонтова?)))

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено myhand , 01-Апр-19 09:59 
Боюсь, ЦА пыхпыха еще сперва придется рассказать что такое матрицы, ибо в школе этого не проходят.  Да и учились они там...

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 19:19 
C массивами, деревьями и прочими структурами - всё нормально. А для быстрого обсчёта матриц проще расширение на сях прикрутить. Или у вас пыхтон умеет ваши матричные расчёты например под AVX/AVX2 оптимизировать? Нет? То-то же.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 19:26 
Если нужна высокая производительность в типовых структурах - есть http://docs.php.net/manual/en/book.ds.php
Впрочем, JIT может это расширение как раз сделать ненужным.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено аноним3 , 01-Апр-19 22:06 
nympy может все))) я конечно понимаю люди язык свой любят и хвалят, но он не для этого создавался. как впрочем и питон не создавался для системного программирования, а для прикладных программ. хотя о чем это я . я как то больше си/с++ предпочтения отдаю. а питон местами где это быстро и удобно. но то что мода пошла на каждый язык писать свой jit.. реально тупизм. язык хорош для того для чего он предназначался. знаешь когда люди хотели ездить быстрее на велосипедах они тоже сначала ставили маленькие моторчики, но потом быстро смекнули, что нужно создать именно мотоцикл. вот в этом и вся разница. первое костыль , а второе полноценное средство передвижения. так и тут.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Vkni , 01-Апр-19 23:51 
Интерфейс numpy - это потрясающее дерьмо.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено аноним3 , 02-Апр-19 01:43 
не всем мышками шарить))

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Vkni , 02-Апр-19 04:52 
Правильнее будет "не всем шарить". ;-)

Я несколько офигел от наличия, скажем, функций amin и nanmin.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено аноним3 , 02-Апр-19 20:16 
кроме этого к питону прикрутить тоже много чего можно. так что тут уж точно PHP в проигрыше. а вот если php гонять по обработке gpx(xml) данных то тут он может быть сильно в выигрыше. но все равно не сильно у него то специфика по обработке системных и подобных направлений. он как был для веб так и остался. вот там действительно его ниша.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено cutlass , 01-Апр-19 02:20 
Это было бы прекрасно!

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 31-Мрт-19 22:11 
Боюсь, "потеснить" случится примерно как в вёбе - 80% vs уровень погрешности.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 02:06 
Подскажите в PHP появилась асинхронность?
Существует ли свой HTTP сервер в PHP (не для отладки, а для производственного окружения)?

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Ононем , 01-Апр-19 04:27 
С какой целью интересуетесь?

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Remote_Code_Execution , 01-Апр-19 07:19 
https://github.com/swoole/swoole-src

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 08:26 
Не забудьте рассказать любезному что нужно будет переписать весь IO код, плюс добавить обзяки что бы это не развалилось

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 08:19 
1. Асинхронность чего именно? Если вы про многопоточное исполнение - таковое вполне реализуется подзапросами (мы так делаем) - накладные расходы не велики, просто надо себя к этому приучить - зато нет целого сопряжённого класса проблем. Механизмы IPC для синхронизации и обмена данными доступны разные.

2. Существует FastCGI-сервер, FPM называется. В качестве HTTP прикручиваете любой удобный вам фронт.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 08:21 
Если же вы про event-driven, то у PHP слегка иная модель работы, но расширения на C имеются. Вон Swoole правильно подсказывают. Из нативных - ReactPHP.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 08:24 
Вообще асинхронные модели работы решают проблему _классических_ языков, у которых приложение исполняет долго, и вынуждено какими-то костылями разбирать запросы в потоки.

PHP асинхронен изначально, by design. Только выглядит это неможно по-другому. С точки зрения кода он всегда имеет одну инстанцию выполнения на один запрос. У этой модели работы другие проблемы - перзистивность данных и синхронизация между инстанциями.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 01-Апр-19 08:29 
Какие у вас широкие рамки асинхронности.
Надеюсь вы просто тролите

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 08:30 
Да нет, я не троллю. Просто привычка к классическому формату у людей вызывает совершенно странные вопросы.

Зачем тащить в PHP event-driven модель, если его модель работы - 1 запрос = 1 процесс изначально?


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 08:34 
У такой модели работы есть здоровенная проблема: время инициализации. Решать проблему минимизации инициализации - задача программиста. Современные гиперфреймворки под пых например как раз болеют оверблоутом инициализации, из-за чего ворочаются очень медленно.

Сам интерпретатор оптимизирован как раз под эту модель работы. Opcache часть проблемы инициализации - длительную предтрансляцию кода - убирает. JIT и кэш JIT решат проблему предтрансляции совсем, и уменьшат время инициализации собственно пользовательского кода.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Онаним , 01-Апр-19 08:29 
Мысли приходят в процессе, поэтому излагаю дальше.

На PHP до какого-то времени из-за его модели работы сложно было писать как раз долго исполняющиеся процессы "классического" формата (один процесс - много запросов). Впрочем, это уже тоже в прошлом. Большинство проблем с утечками памяти где-то в 5.5 вылизано до блеска, оптимизирован GC, и долго живущие процессы теперь работают прекрасно. У нас таким образом работают различные реалтайм коллекторы, обмен данными с интерфейсами сделан через ZeroMQ.


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено rex , 05-Апр-19 20:33 
т. е. граф объектов в памяти расшарить между потоками нереально?

Как писать такое (js):
const a = { b: c }
const f = d => ({ ...a, d: d })
на PHP?:
как дела с лямбдами, обязательно ли городить function-use-return?
есть ли средства проверки пропущенных use-return?
есть ли способ помечать переменные, как однократно или многократно присваемые и проверять?
есть ли иммутабельные структуры, и как у них с производительностью и вербозностью?

или это всё тоже не надо с маленькими-короткими процессами?


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Попугай Кеша , 01-Апр-19 09:17 
php - малый/средний бизнес/школьники/студенты
java/.net - крупный бизнес

Тчк.

Это Россия, детка

Ruby/Python/Rust/Go - эльфы из Средиземья


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 02-Апр-19 15:18 
Да будь я хоть вокзальной пирожковой, никогда бы не взял похапэху как технологию! Это же смешно. Неосиляторы Перла придумали неуклюжий недоязык, якобы что-то там облегчающий. Это как взять русский и выкинуть из него падежи - поди, пойми, что чеговек сказал!

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Деннис Ритчи , 01-Апр-19 12:34 
>> При этом после внедрения JIT кардинального роста производительности для web-разработчиков не предвидится...

xD


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Remote_Code_Execution , 01-Апр-19 12:41 
Нужно переписать весь код как Си экстеншен тогда будет ОК!

https://zephir-lang.com/ru-ru


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Jkeks , 01-Апр-19 20:38 
Пусть сначала добавят работу с буфером обмена

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 02-Апр-19 01:23 
>  благодаря повышению производительности при выполнении таких задач как 2D- и 3D-рендеринг

Ждем портирования Unreal Engine на php


"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Аноним , 02-Апр-19 15:16 
PHP... "переосмыслить"... как-то вообще не вяжутся в одном предложении похапэха с наличием мозгов. У кого были мозги, те таки осилили Перл!

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Denis Duke , 29-Июл-19 10:44 
Отличная статья, "коротко о главном", спасибо за труды. Читал сегодня тоже отличный пост по теме PHP, https://writeabout.tech/marketing/who-is-an-seo-specialist-2/ , может ещё кому пригодится.

"В PHP 8 будет добавлен JIT-компилятор"
Отправлено Denis Duke , 14-Авг-19 15:47 
Спасибо за пост. Круто что всегда можно найти много развёрнутой информации. Читал сегодня днём тоже хорошую статью по теме, https://writeabout.tech/programming/php8/, думаю ещё кому то пригодится.