Например, в спецификации описано, как работает конвейеризация HTTP, но, если вы попробуете задействовать эту фичу «на местности», то сами напрашиваетесь на проблемы и… всё окончится грустно.
Верно подмечено. Я изучал имплементацию pipelining'а на примере некоторых топовых фреймворков из списка TechEmpower FrameworkBenchmarks. Разрабы делают реализацию просто в лоб и тупо. К примеру, если скорость приёма сервера больше, чем его отдача, то просто пожирается память на выделение всё новых буферов в памяти.
Я же в проекте fastwsgi сделал эту часть HTTP-сервера по умному. Т.е. сервер умеет притормаживать чтение входящих запросов, в зависимости от состояния части, отвечающей за отправку данных.
---------------
Ну и ссылочка на топик, где я сетую на то, что в Python-лидерах находится "поделка", которая просто базовые требования TCP-сервера не соблюдает, не то что HTTP:
я уверен, что когда докладчик с горящими глазами, и дрожащим голосом, рассказывает про ужасы и показывает что мол вот смотрите че может быть когда разработчик не понимает что он делает, а фреймфорк не читает мысли того самого разработчика и вот ужас, мы накрутили процентов... ну да, я уверен что все проголосуют что уязвимость....
в копиляторе С кстати дохера таких, например, когда пытаешься прочитать непроинициилизированный поинтер, а компилятор ничего с этой попыткой не делает
Мде. Походу челы ваще не понимают как нативный код работает, коли ждут от Сишечки проверок.
Я вот тоже недавно решил сделать open source утилиту для вывода инфы о железе и его параметрах. Решил делать именно на питоне, т.к. порог вхождения контрибьютеров будет поменьше. Да и не нужен нативный код для таких задач.
Для работы с оборудованием использую не устаревший winring0, а cpuidsdk(cpuz.sys), на который антивири не ругаются.
Вот и вспомнилось сразу, как пришлось костыль делать в проекте FastWSGI. На самом деле при написании кода под WSGI интерфейс возникло очень много вопросов к авторам сия придумки. Довольно затратны процессы сериализации/десериализации. Сразу вспоминается HTTP-протокол: HTTP 1.x придумали псевдо-программисты, а HTTP 2.x (и далее) - настоящие программисты.
Так вот, одной из проблем WSGI является использование BytesIO. И добавить в поток байтиков можно только Py-объект (для этого используется функция _io_BytesIO_write).
А функцию для добавления сразу "сырого" куска из памяти (char * bytes) в CPython не завезли.
Среди китайцев есть ptpt52, который довольно активно коммитит в офиц. репозиторий OpenWrt. И у него есть и свой форк OpenWrt: https://downloads.x-wrt.com/rom/ Сборки X-WRT отличаются от офиц. сборок.
У меня как то язык не повернётся назвать это "сборкой китайского васяна".
На данный момент - это лучший вариант... диапазон цен 4500-5500р
про RT-AX53U (mt7621A):
Находится в том же диапазоне цен, но железо чуть слабее. У Redmi выше тактовая частота, а значит, он в теории будет лучше справляться с шифрованием данных. Для роутера в наших реалиях - это в первую очередь туннели OpenVPN, Wireguard итд. По бенчмаркам MT7622B лучше почти в два раза
Видимо вы неверный вывод сделали из статьи 2023 года.
Появление в 2023 году устройств с mt7622 и mt7981b изменило расклад. Старый чип mt7621 явно стал не актуален. Да и в 2024 году почти каждому стал нужен шифрованный туннель в роутере.
Среди Кинетиков только сейчас появились модели на mt7981b (в 2023 году там правил балом mt7621 и его клоны).
Наверное стоило упомянуть, что у ASUS TUF-AX6000 есть полная копия в виде ASUS TX-AX6000 (просто другой корпус, продаётся только на китайском рынке).На озоне его продавали зимой за 13500руб.
ASUS TX-AX6000 занял в одном из китайских тестов первое место по соотношению цена/производительность:
Есть галактики, расстояние до которых превышает 13 млрд. лет.
Расширение пространства не ограничивается скоростью света. Из-за этого мы и можем только наблюдать за галактиками только в определённой сфере. Всё остальное за этой сферой мы не увидим никогда.
В этом списке явно не хватает PVS-Studio!
Codacy вообще бесполезен (самый кривой в этом списке).
У Coverity очень ужасный WEB-интерфейс.
LGTM игнорит windows проекты.
Кстати, Coverity заинтегрировался с Travis-CI. Было бы здорово, что бы PVS-Studio заинтегрировался с AppVeyor (что бы свою сборочную систему не городить).
Да даже и без интеграции с AppVeyor можно обойтись.
Как юзать CoverityScan совместно с AppVeyor
К примеру, на сервере AppVeyor уже лежит дистр CoverityScan, который нужно перед сборкой скачать. После выполнения cov-build результаты кладуться в архив и через WEB-форму заливаются на сервер Coverity. Там результаты прогоняются через cov-analyzer и на персональной страничке проекта появляются результаты (эта страничка ужасна).
… потому что драйвера в BSP доступны только в виде бинарников, а интерфейсы ядра изменились и нужен новый BSP
Тут вы правы. В китайском инете можно скачать исходники BSP для Qualcomm и MTK (китайские разрабы очень безолаберно относятся к безопасности).
А производитель, какой-нибудь Qualcomm, не хочет ни портировать (потому что нерентабельно)
Не совсем правы. К примеру, Qualcomm до сих пор поддерживает старую платформу msm8x26. Месяц назад HTC даже выпустила новый телефон на чипе msm8926, релиз которого был аж в 2013 году. Причём там используются исходники BSP для 6-го дройда.
Просто эти самые исходники Qualcomm продаёт вендорам. Только крупные вендоры (HTC, Samsung, Sony, etc) могут позволить себе покупать новые сорцы ради обновления дройда на бюджетных устройствах.
… ни давать исходники (потому что, говорит, коммерческая тайна)
Разбирался. Всё так и есть. Даже было время, когда на работе 99% такую же железку взял и установил там некоторые бенчи и лично проверил:
https://github.com/TechEmpower/FrameworkBenchmarks/issues/7402#issuecomment-1482918369
Получил довольно близкие цифры.
Раньше у них стояли 10Gbit сетевухи, а теперь уже 40Gbit. Мне на работе удалось проверить только 10Gbit и 25Gbit.
Вот точный конфиг: https://github.com/TechEmpower/FrameworkBenchmarks/issues/8736#issuecomment-1973835104
Верно подмечено. Я изучал имплементацию pipelining'а на примере некоторых топовых фреймворков из списка TechEmpower FrameworkBenchmarks. Разрабы делают реализацию просто в лоб и тупо. К примеру, если скорость приёма сервера больше, чем его отдача, то просто пожирается память на выделение всё новых буферов в памяти.
Вот тут я немного возмущался: https://github.com/TechEmpower/FrameworkBenchmarks/discussions/8048
Я же в проекте fastwsgi сделал эту часть HTTP-сервера по умному. Т.е. сервер умеет притормаживать чтение входящих запросов, в зависимости от состояния части, отвечающей за отправку данных.
---------------
Ну и ссылочка на топик, где я сетую на то, что в Python-лидерах находится "поделка", которая просто базовые требования TCP-сервера не соблюдает, не то что HTTP:
https://github.com/TechEmpower/FrameworkBenchmarks/issues/9055
Вот такие чудеса на виражах.
Мде. Походу челы ваще не понимают как нативный код работает, коли ждут от Сишечки проверок.
Я вот тоже недавно решил сделать open source утилиту для вывода инфы о железе и его параметрах. Решил делать именно на питоне, т.к. порог вхождения контрибьютеров будет поменьше. Да и не нужен нативный код для таких задач.
Для работы с оборудованием использую не устаревший winring0, а cpuidsdk(cpuz.sys), на который антивири не ругаются.
Пока основное направление - тайминги DDR5.
Поиск сорцов по названию: pyhwinfo
Что за ересь то? У вас в примере изначально указано число, которое не может хранится во float8 без потери точности. Сложение тут вообще не причём.
Эта статья уровня школьных рефератов. Да ещё 4 плюсика уже есть... за что?
Знакомый код.
Вот и вспомнилось сразу, как пришлось костыль делать в проекте FastWSGI. На самом деле при написании кода под WSGI интерфейс возникло очень много вопросов к авторам сия придумки. Довольно затратны процессы сериализации/десериализации.
Сразу вспоминается HTTP-протокол: HTTP 1.x придумали псевдо-программисты, а HTTP 2.x (и далее) - настоящие программисты.
Так вот, одной из проблем WSGI является использование BytesIO. И добавить в поток байтиков можно только Py-объект (для этого используется функция
_io_BytesIO_write).А функцию для добавления сразу "сырого" куска из памяти (
char * bytes) в CPython не завезли.И вот пришлось самому конструировать этот механизм вот таким образом: https://github.com/jamesroberts/fastwsgi/blob/5572bb31b859d690be225707b9e7e25af397544b/fastwsgi/pyhacks.c#L148-L154
Хотя много где в CPython есть методы, которые позволяют передавать им "сырые" куски памяти через
char *, но вот вbytesio.cтакие забыли завести.Вот с чем может быть связана такая забывчивость?
И можно ли было обойтись без костылей, реализованных в pyhacks.c ?
PS.: нагуглил тут похожую проблему и на чистом питоне https://stackoverflow.com/questions/78399639/how-to-use-io-bytesio-in-python-to-write-to-an-existing-buffer
Среди китайцев есть ptpt52, который довольно активно коммитит в офиц. репозиторий OpenWrt.
И у него есть и свой форк OpenWrt: https://downloads.x-wrt.com/rom/
Сборки X-WRT отличаются от офиц. сборок.
У меня как то язык не повернётся назвать это "сборкой китайского васяна".
Так и в статье 2023 года @itdog писал такое:
про AX6S (mt7622B):
про RT-AX53U (mt7621A):
Видимо вы неверный вывод сделали из статьи 2023 года.
Появление в 2023 году устройств с mt7622 и mt7981b изменило расклад. Старый чип mt7621 явно стал не актуален.
Да и в 2024 году почти каждому стал нужен шифрованный туннель в роутере.
Среди Кинетиков только сейчас появились модели на mt7981b (в 2023 году там правил балом mt7621 и его клоны).
Наверное стоило упомянуть, что у ASUS TUF-AX6000 есть полная копия в виде ASUS TX-AX6000 (просто другой корпус, продаётся только на китайском рынке).На озоне его продавали зимой за 13500руб.
ASUS TX-AX6000 занял в одном из китайских тестов первое место по соотношению цена/производительность:
Источник: https://youtu.be/Z72ooqxaYb8?t=506
Расширение пространства не ограничивается скоростью света. Из-за этого мы и можем только наблюдать за галактиками только в определённой сфере. Всё остальное за этой сферой мы не увидим никогда.
А вот как удобный и понятный WEB-интерфейс с результатами сгенерировать? Вот в чём вопрос.
Codacy вообще бесполезен (самый кривой в этом списке).
У Coverity очень ужасный WEB-интерфейс.
LGTM игнорит windows проекты.
Кстати, Coverity заинтегрировался с Travis-CI. Было бы здорово, что бы PVS-Studio заинтегрировался с AppVeyor (что бы свою сборочную систему не городить).
Да даже и без интеграции с AppVeyor можно обойтись.
github.com/stormctf/Meltdown-PoC-Windows/tree/master/Meltdown/x64/Debug
Эти байтики находятся в самом начале образа ntoskrnl.exe (см. на картинке ряд real).
github.com/stormctf/Meltdown-PoC-Windows/tree/master/Meltdown/x64/Debug
Эти байтики находятся в самом начале образа ntoskrnl.exe (см. на картинке ряд real).
Не совсем правы. К примеру, Qualcomm до сих пор поддерживает старую платформу msm8x26. Месяц назад HTC даже выпустила новый телефон на чипе msm8926, релиз которого был аж в 2013 году. Причём там используются исходники BSP для 6-го дройда.
Просто эти самые исходники Qualcomm продаёт вендорам. Только крупные вендоры (HTC, Samsung, Sony, etc) могут позволить себе покупать новые сорцы ради обновления дройда на бюджетных устройствах.
Всё то, что мне удалось слить с китайского инета, ищите тут: http://syshwid.blogspot.ru/2016/08/build-qualcomm-modem.html