- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
// https://habr.com/ru/company/oleg-bunin/blog/493242/
// Алгоритмы быстрой обработки HTTP-строк
// .....
// Как устроен парсер? Мы, как nginx, определяем массив байт и по нему
// проверяем входные данные — это пролог функции. Здесь мы работаем
// только с короткими сроками, используем likely, потому что branch misprediction
// для коротких строк болезненнее, чем для длинных. Выносим этот код наверх.
// У нас есть ограничение в 4 из-за последней строчки — мы должны написать
// достаточно мощное условие. Если будем обрабатывать больше 4 байт, то условие
// будет тяжелее, а код медленнее.
static const unsigned char uri_a[] __attribute__((aligned(64))) = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
...
// Branch misprediction is more crucial for short strings
if (likely(len <= 4)) {
switch (len) {
case 0:
return 0;
case 4:
c3 = uri_a[s[3]];
// fall through to process other chars
case 3:
c2 = uri_a[s[2]];
case 2:
c1 = uri_a[s[1]];
case 1:
c0 = uri_a[s[0]];
}
return (c0 & c1) == 0 ? c0 : 2 + (c2 ? c2 + c3 : 0);
}
// Основная петля и большой хвост. В основном цикле обработки мы делим
// данные: если они достаточно длинные, обрабатываем по 128, 64, 32 или
// по 16 байт. Имеет смысл обрабатывать по 128: мы параллельно используем
// несколько каналов процессора (несколько pipeline) и суперскалярность процессора.
for ( ; unlikely(s + 128 <= end); s += 128) {
n = match_symbols_mask128_c(__C.URI_BM, s);
if (n < 128)
return s - (unsigned char *)str + n;
}
if (unlikely(s + 64 <= end)) {
n = match_symbols_mask64_c(__C.URI_BM, s);
if (n < 64)
return s - (unsigned char *)str + n;
s += 64;
}
if (unlikely(s + 32 <= end)) {
n = match_symbols_mask32_c(__C.URI_BM, s);
if (n < 32)
return s - (unsigned char *)str + n;
s += 32;
}
if (unlikely(s + 16 <= end)) {
n = match_symbols_mask16_c(__C.URI_BM128, s);
if (n < 16)
return s - (unsigned char *)str + n;
s += 16;
}
... пиздец. Там еще в той статье пишут, что CloudFlare через AVX2 какое-то говно оптимизируют в говнопаринге http запросов.
Поэтому я за бинарную сериализацию, без всей этой хуйни человекочитаемой
Follow us!
... вообще, вспоминается еще вот эта параша https://govnokod.ru/24338 - там тоже какая-то такая поебень
Или вот https://govnokod.ru/19842 там вконтактовские олимпиадники свою питушню на длину проверяют, и только потом сравнивают
или вот
Это лишь тупые анскиллябры опускаются до макросов, а Доктора Наук умеют сами считать размер строк
Детали не помню, они жали хедеры, но злоумышленник мог слать хитрые запросы, угадывать какие хедеры в ответе и какой контект архиватора и через это как-то сильно упрощалось дешифровка SSL.
Вообще все эти SPDY и HTTP/2 с их словарным зожатием зоголовков, по сути откат к бинарным протоколам.
Царь мудр. А птушники колются, но продолжают дрочить на текстовую питушню.
Если SSL TLS не похуй на контент и при каких-то данных он становится слабее - то это всё-таки TLS хуёво спроектирован, а не прикладной протокол, который поверх него гоняют.
Как в таких ебанутых условиях вообще удаётся сделать что-то малость безопасное - х.з.
В коммерции, кстати, используется такая же хуйня, но в более извращённых и тёмных формах, см. «pixel tag».
Ко-кок, ко-кок.
Просто сначала анскилябры сделали HTTP текстовым протоколом.
Время шло, траффик рос, все стали видеть реальный пирформанс и осознавать масштабы факапа.
Тогда отбросы стали прикручивать к протоколам зожатие и на каждом углу орать, как это круто.
По сути вернувшись к бинарным протоколам.
И что в итоге вышло? Всё что было заявлено — со всем обосрались.
Кукарекали, что-то про читабельность текста — обосрались и начали архивировать.
Кукарекали, что бинарь не нужен, а сами сделали уязвимый бинарь.
Но обычный "безобидный" GET или POST вполне доходит до сервера. Чего в общем-то и было достаточно для обсуждаемых здесь атак.
Сходи, проверь уже. Даже ваершарк запускать не надо, браузерной сосноли будет достаточно. Кинь кросс-доменный запрос с какого-нибудь ГК на какое-нибудь ВК и убедись, что браузер и сервер этот запрос обработали, а твоему скрипту просто ответ не отдали.
З.Ы. Ну что, фаза отрицания пройдена? :)
При этом злоумышленник на его домене вправе разрешить его скриптам ходить на твой домен. Браузер даже куки будет отправлять. Чего вполне достаточно для рассматриваемых в данном треде атак. А то что его скрипт ответ не получит - всем похуй.
Если злоумышленник хочет отправлять запросы от имени своего домена куда угодно, то CSP ему никак не помешает.
При этом ты, как админ сайта, вообще ничего не можешь сделать. Разве что отрубить HTTP/2.
Ты в кафешках, метро и т.п. вайфаем пользуешься?
Задача — спиздить куки пользователя от сайта vk.com. «vk.com» открывается только по «https».
Браузер идёт запросом в вк, злоумышленник снифает куки.
2) Уговорить юзера зайти на твой сайт (это очень просто т.к. бесплатный вайфай обычно открывает страничку приветствия)
3) Кидать специально сформированные запросы на ВК
4) Смотреть на их длину в трафике
5) Профит
Но, конечно, это всё уже заткнули кривыми костылями в духе принудительной фрагментации. Поэтому в такой простой форме оно уже не работает.
>>> It relies on the attacker being able to observe the size of the ciphertext sent by the browser while at the same time inducing the browser to make multiple carefully crafted web connections to the target site. The attacker then observes the change in size of the compressed request payload, which contains both the secret cookie that is sent by the browser only to the target site, and variable content created by the attacker, as the variable content is altered. When the size of the compressed content is reduced, it can be inferred that it is probable that some part of the injected content matches some part of the source, which includes the secret content that the attacker desires to discover.
1) пруф владения сертом сервера в данный момент
2) цепочку подписанных сертов от серверного до корневого
Это — забота того центра сертификации, у которого ты купил (получил) серт.
> и только его?
А для этого ты должен верить джентльменам, которые выпускают сертификаты, на слово.
Таким образом, если спецслужбы сгенерируют себе кучу сертификатов, то либо они (сертификаты) не будут работать, либо их придётся загрузить в публичный лог, о чём сразу же узнают недовольные владельца сайтов.
https://www.certificate-transparency.org/what-is-ct
Какое доверие )))
https://www.certificate-transparency.org/log-proofs-work
Ну и «CT» — это инициатива «Гугла», они себе могут позволить десяток корневых DNS запустить и не особо просесть по баблу.
Поэтому вся криптоархитектура современного веба строится на том, что для успешного взлома системы (получения доверенного сертификата на чужой домен) тебе придётся взламывать много разных сервисов.
*Поле есть, но по факту в проверке доверия оно не участвует.
> размести CA в США, Европе, КНР и России. требуй 4х подписей
Это чрезвычайно сильно усложнит процедуру получения сертификата и увеличит вероятность отказа. К тому же, текущая система доверия просто не рассчитана на такое: в ней существует отдельных «сертификатов CA», в ней есть только подписанные и самоподписанные сертификаты. Более того, у CA обычно есть несколько (меняющихся) сертификатов, связанных в цепочку, и сертификаты клиента подписываются самой нижней «частью». Например: https://letsencrypt.org/certificates/.
> даже в книжке про PKI в доменной винде рекомендовалось корневой CA держать выключенным, а выдать другим (более мелким питухам) право выдавать серты.
Ну да, всё правильно. Корневые HTTPS-сертификаты держат за семью замками в камере из вибраниума и достают только по очень-очень большим праздникам.
Если у нас есть только один CA на страну, то вместе с его отключением выключится и интернет. Если CA много, но надо подписи из разных стран, то нужно в сертификаты вводить, собственно, информацию о «гражданстве» CA — а это огромный геморрой. Плюс возникают политические проблемы. Плюс ничего не мешает хакерам из ФСБ взломать четыре CA из Зимбабве, Нигерии, Либерии и Лимпопо, после чего спокойно штамповать серты для google.com.
угу. Приватный ключ самого корневого CA хранится вообще под семью замками, и ради питухов его не достают.
>что в таком случае помешает ФСБ взять четыре CA в России,
Я предлагаю требовать подпись минимум четырех CA из разных стран
Без Лимпопо и Уганды. А чтобы взломать и ФСБ и ЦРУ надо быть очень крутым
>> Плюс возникают политические проблемы.
> требовать подпись минимум четырех CA
Опять же, в системе доверия просто нет никаких «CA», есть только сертификаты. Нельзя достоверно определить, что два сертификата были выпущены разными CA.
> А чтобы взломать и ФСБ и ЦРУ надо быть очень крутым
Не нужно взламывать ФСБ и ЦРУ, достаточно послать четырёх людей в штатском, которые занесут по чемодану бабла четырём условным директорам CA.
Инстансов корневых DNS тоже нет в лимпопо, это создает проблемы? Ну посадите один в африке в ЮАР, там же шафт уже есть.
>Нельзя достоверно определить, что два сертификата были выпущены разными CA.
Чтобы проверить сертификат, мне нужно пороверить его подпись. Чтобы проверить подпись, мне нужно знать публичный ключ подписавшего его товарища. Публичный ключ я беру из корневого самодподписанного серта.
Разные серты -- разные ключи.
Разумеется, ничто не мешает мне самоподписать чужой серт, но его же тогда в ОС и либы не вбандлят.
>которые занесут по чемодану бабла четырём условным директорам CA.
Тогда сейчас еще хуже: достаточно одного чемодана в LetsEncrypt, нет?
Они не решают проблему доверия, поэтому это не столь важно. К тому же, реплику корневого DNS вполне можно разместить хоть в Лимпопо, хоть в Зимбабве — никаких проблем это не создаёт.
> Публичный ключ я беру из корневого самодподписанного серта.
> Разные серты -- разные ключи.
>>> Корневых сертификатов очень мало, их просто не хватит на все CA.
> Тогда сейчас еще хуже: достаточно одного чемодана в LetsEncrypt, нет?
Именно. Для решения (не полного, разумеется, полностью решить проблему доверия нельзя) этой проблемы и придумали «Certificate Transparency». Если ты занесёшь чемодан в «LE», то они тебе смогут выпустить только сертификат, не записанный в публичный лог, потому что иначе их мгновенно выебут, высушат и все сертификаты отзовут. А сертификату, не записанному в публичный лог, браузер доверять не будет (сейчас — с «expect-ct», потом вроде как вообще планируется сделать такое поведение дефолтным). Обойти это можно только для точечных атак на одного пользователя, занеся по чемодану бабла владельцам публичных логов и заставив их отдавать фиктивный ответ только одному айпишнику. При этом вероятность провала увеличивается, потому что если кто-то заметит фиктивные ответы от лога — лог тоже выебут и высушат.
Есть Корневой CA. Он сам себя подписал (как языческий бог сам себя родил). Его приватный ключ хранится в подвале ООН, охраняемый солдатами (по четыре от каждой страны).
Раз в год он выдает Сертификаты четырем странам в ЕС, США, РФ и в КНР.
Все четыре страны обязаны подписать сертификат govnokod.ru.
В браузер вшит только Корневой (из подвала ООН). Остальные он валидирует.
Во-вторых, если ты на своём сайте разместишь картинку с Винни Пухом, то КНР обидится и откажется подписывать твой сертификат — и всё, не будет у тебя «HTTPS».
В-третьих, если в США негры разъебут местный CA, то выдача сертификатов прекратится во всём мире — то есть у нас даже не единая точка отказа, у нас их аж четыре, причём отказ каждой из них отключает всю систему.
В-четвёртых, в такой системе достаточно спиздить корневой сертификат — и можно подписывать что угодно. «CT», в свою очередь, эффективно защищает даже от кражи корня.
Нет, я не спорю, что это весьма эффективная стратегия для валидации каких-то критически важных мировых ресурсов, но в качестве глобальной системы доверия для HTTPS её преимущества сильно перевешиваются минусами.
А валидация логов усложняет использование сертификата. Это как OCSP, только плюс еще одно действие. нет?
>Во-вторых, если ты на своём сайте разместишь картинку с Винни Пухом, то КНР обидится
А лецэнкрипт не обидится? А шафт? А верисайн?
А если я УсамаБинЛанден младший, и делаю сайт про 9/11, то американцы мне дадут сертификат?
>причём отказ каждой из них отключает всю систему.
Предлагаю всё равно выдавать серты, но писать рядом сними кто их подтвердил
Пользовтаель пусть сам решает кому он доверяет в зависимост от своих политическх предпочтений
>в такой системе достаточно спиздить корневой сертификат
Из подвала ООН?
>«CT», в свою очередь, эффективно защищает даже от кражи корня.
Но не защищает от 51% кажется что.
Достаточно завладеть всеми серверами логов, и можно вертеть всех на хую.
Это один запрос, который ты можешь закэшировать навечно. Лишние 100 миллисекунд на первое открытие сайта — не такая уж страшная цена.
> А лецэнкрипт не обидится? А шафт? А верисайн?
> А если я УсамаБинЛанден младший, и делаю сайт про 9/11, то американцы мне дадут сертификат?
Обидится «Let's Encrypt» — ты спокойно сможешь пойти к «VeriSign». Обидится «VeriSign» — пойдёшь к «Namecheap». Обидится любой американский CA — купишь сертификат у «Reg.ru». ФСБ потребуют ключи — переедешь в австралийский «ssltrust.com.au». В этом и суть.
> Пользовтаель пусть сам решает кому он доверяет в зависимост от своих политическх предпочтений
Ну а в чём тогда смысл всей системы, если обеспечение безопасности всё равно в конце-концов перекладывается на пользователя?
Вообще, считать, что среднестатистический пользователь хоть чуть-чуть разбирается во всех этих ваших сертификатах и цепочках доверия — это огромная ошибка, так делать не нужно.
> Из подвала ООН?
Совершенно неважно, откуда.
> Но не защищает от 51% кажется что.
Нет, там, ЕМНИП, каждый лог независим.
> Достаточно завладеть всеми серверами логов, и можно вертеть всех на хую.
Целостность данных в логах постоянно проверяется независимыми аудиторами. Если что-то идёт не так — бьётся тревога, и все скомпрометированные логи ебут и сушат.
Ну ладно, не вечно, на год будем кэшировать, благо сертификаты в общем и целом примерно через столько и протухают.
Предположим, что за год пользователь посещает миллион сайтов, каждый из которых за это время сменяет по пять сертификатов. Тогда в кэше у пользователя окажется (мы параноики и используем 64-батный хэш) 5*64*1000000/(1024*1024) = 305.17578125 мегабат данных. Не выглядит страшной потерей места. Конечно, в реальности доменов будет ещё меньше: у меня, например, за последний год в истории значится 4540 доменов.
> половина логов говорит одно, половина -- другое
> твои действия?
Единственный лог, говорящий об отсутствии в нём соответствующего сертификата — повод для провала валидации. Если я замечаю, что два разных лога дают разные ответы — я пишу в Спортлото операторам логов, после чего скомпрометированные логи ебут и сушат.
Вообще, вся эта инфа есть у них на сайте:
https://www.certificate-transparency.org/log-proofs-work
https://www.certificate-transparency.org/getting-started#TOC-Verifying-SCTs
UPD: ну и я несколько неточен, запросы к логам слать не обязательно, достаточно проверить, что у сертификата есть reasonable number of SCTs with valid signatures. «SCT» — это такой штампик, удостоверяющий, что соответствующий лог поместил в себя соответствующий сертификат.
Логика сёмы.
Ему все всё должны разжевать в рот положить.
И если вдруг комп выкинут нерабочий, он обязательно на это пожалуется.
https://www.certificate-transparency.org/known-logs
Вся фишка же в них.
Поднять свою же. Отличить нормальную точку от поддельной в том же метро невозможно. Именно поэтому я никогда не юзаю бесплатный вайфай без VPN.
Да там и более очевидные дыры есть... Про скан твоей локалки из браузера с помощью DNS злоумышленника, к примеру. И это 10 лет никто не фиксил и вроде даже не собирается.
Повторюсь - корень зла именно в том, что браузер позволяет кому угодно кидать запросы куда угодно.
reload=5 или как там в хедерах.
А юзеру не похер какой тебе софт показывает контент: бинарный или текстовый.
Никто же не читает сырые запросы. Максимум что делают руками: шлют курлом. Но и его тоже можно пропатчить и слать бинарники.
Но да, это работает только в случае хорошего владельца сайта и плохих пользователей.
2. Классика CSRF: кроссдоменный AJAX по умолчанию запрещён, но никто не мешает вставить URL запроса в элемент <img> или <script>.
> запрос не пойдёт
?
Какое секьюрити )))
Криптостойкий надеюсь? А не хуйня, которую временем и номером процесса засидили?
> уникального ID сайта
Насколько уникального? Могу ли я забыть его вписать? Есть ли какая-то утечка данного id?
Вопрос исключительно к джанге, только они решают какой генератор будет использоваться и чем они будут его сидить. Наличие хороших генераторов в ОС не отменяет говна на стороне софта. Хоть это и не пыхомакаки, конечно.
> считается что нет
Ну ок. В целом выглядит норм. Даже с плохим генератором должно вытянуть если этот секрет не утечёт (хотя конечно надо бы уточнить насколько качественно он сгенерён).
А ты оптимист. Нельзя с таким отношением с безопасностью работать.
> кидать произвольные запросы куда угодно, а потом просто прячут от него ответ если вдруг нельзя было.
Если DNS злоумышленника имеет очень маленький TTL, то он может вращать IP домена, с которого был загружен скрипт. И тем самым для этого скрипта все твои девайсы в локалке будут same origin со всеми вытекающими последствиями - скан, подбор пароля, анальный зонд в роутере.
Атаку, насколько я помню, воскресили из-за всяких биткоин кошельков и прочей хуйни с локальными веб-интерфейсами. Почему-то считается, что порт на 127.0.0.1 - это достаточная защита и туда никто не пролезет.
> то это всё-таки TLS хуёво спроектирован
Нет, там уязвимость давал архиватор.
Точнее целое семейство уязвимостей: CRIME, BEAST, BREACH.
It relies on the attacker being able to observe the size of the ciphertext sent by the browser while at the same time inducing the browser to make multiple carefully crafted web connections to the target site. The attacker then observes the change in size of the compressed request payload, which contains both the secret cookie that is sent by the browser only to the target site, and variable content created by the attacker, as the variable content is altered. When the size of the compressed content is reduced, it can be inferred that it is probable that some part of the injected content matches some part of the source, which includes the secret content that the attacker desires to discover.
Там был прикол именно в сайд-эффекте от архивации текстов. Ворецируя куски запросов, можно было смотреть как меняется архивированная длина, и угадывать части текста в кукисах, совпадающие с ворециями в запросе.
В случае бинарного протокола с фиксированной длиной такой питушни бы не было.
Ну вот собственно и ключевой момент, вся суть веб-параши.
Эти мудаки сами пустили злоумышленника на атакуемую тачку и дали ему право кидать произвольные запросы на сайты, к которым он не имеет никакого отношения. За каким хуем?!
А потом начали чинить там где не сломано (безобидное зожатие).
Они и с бинарным протоколом с фиксированной длиной тебе оракула породят. С такой то "моделью безопасности". Хотя это, конечно, будет сложнее.
> Детали не помню, они жали хедеры, но злоумышленник мог слать хитрые запросы, угадывать какие хедеры в ответе и какой контект архиватора и через это как-то сильно упрощалось дешифровка SSL.
Ну тут всё более-менее понятно, ведь зожимая текстушню, мы получаем разный размер в зависимости от того, какая текстушня была зожата, и по размеру зожатой текстушни можно там что-то угадывать. Но бинарнушня от этого тоже может поцтрадать, если эта бинарушня имеет разный размер в зависимости от некоторой хуйни, которую в нее сериализовали, или если ее тоже каким-то хером зожимают. Тут всё достаточно сложно, и вообще хер там плавал.
Можно просто сделать чтоб там заголовок имел фиксированный размер в байтах, и тогда такой хуйни не будет.
Бинарушня будет занимать меньше места, иметь фиксированный размер и парситься сишкой автоматом.
А текстушня плавающей, неудобной в парсинге.
> Зная размеры конкретных картинок, можно по размеру передаваемой шифрованной хуйни таким образом понять, какие конкретно картинки запрашивались
Эээ. Если на порносайте миллионы картинок, то неизбежно будут коллизии.
Тем более откуда уверенность что там зашифрованна картинка, а не какой-то скрипт?
>даже в периоды неактивности срать каким-то мусором, даже если пользователь нихуя не запрашивает
Это и так происходит. На многих сайтах есть polling и просто xhrы.
Если подряд просматривать картинки из какого-то сета, т.е. открывать сначала первую, потом вторую, третью и так далее - тут уж можно понять, что есть на том сайте такой-то набор картинок, первая картинка столько килобайт занимает, вторая - столько и так далее - таким образом можно понять, что вот этот конкретный сет просматривался. И тут уже с коллизией сложнее
Перепитушня.
Это уже по сути timing атака
Мудифицируя X (индекс в строке), Y (ASCII-код символа) и условие (<, >, =) можно быстро (за ~8*len(secret_field) операций) подбирать значения полей даже тогда, когда в ответ вообще ничего не возвращается.
Правда непонятно практическое применение. Зачем вообще надо писать sleep в запросе?
А, я понял, мы сами его инжектим.
Так я же об этом и твержу.
Как бы делал я или царь?
Метод кодируется байтом, вместо GET/POST/PUT/PATCH = enum {1,2,3,4..}
Жопулярные хедеры кодируются не текстом, а тоже байтами.
Для штук типа Content-Type значения контента тоже выбираются из таблицы.
А вот для юзеринпутов типа куков и прочей юзерагент питушни — вореабельные строки.
Тогда по-крайней мере размер хедеров не будет пидорасить размер ответа.
И парсить удобнее, т.к. формат бинарный.
Джвух бат зожатия информации не хватит?
65535 вореций хедеров.
>и как делать webdav и прочие расширения?
Сделать диапазон пользовательских кодов.
Которые могут стать стандартами де-факто.
Царь опять прав оказался. ЧСХ.
Лежит поле богато, в нём нора засрата,
Там срамной порог, там живёт хорёк.
Поди с раба Божьего (имя)
На ту нору вся грязь с нутра:
Коли, охи, ахи, вздохи, слёзы,
Маета, боли живота.
Поди, дристунья, на ту нору. Аминь.
Видать, прав был Чехов, когда сказал, что искоренить совсем "грязь" невозможно, ее можно только прогнать на другое место.
территоге
подозрителевизороге
форумеется
предлагодаря
катастрофит
багоритму
аметит фикат
зловременем
сервероверить
читаемодан
пирформированному
поебень-очень
встратегия
целевога
серверия
developerating
парамечаю
благоворные
роутерфейсами
пыхомать
Криптостальное
вертификаты
говорециями
Пишут, что в десятке таки запилили отдельный масштаб окошек на каждый моник.
На одном рисуется b, на другом — l.
У меня шрифт 10pt на одном мониторе имеет размер N пикселей, а на другом N*4.
Как можно отрендерить его, когда для разных резолюшено разные хинты?
Но опять же, мне кажется что майки пошли по консервативному пути чтобы не испортить существующий софт и кусок окна на одном из моников будет тупо мыльным.
* меняем DPI (Xft.dpi и xrandr --dpi)
* запускаем прогу
* меняем обратно
Получается боль-мень нормально, но если такую прогу утащить на другой монитор, то она конечно превратится в тыкву
При переходе с моника на моник видно как прога адаптируется под новый масштаб. Просто все окно в целом становится мельче или крупнее. Т.е. на мониках с реально разным дпи это будет смотреться довольно хуёво.
Но, к слову, часто ли ты юзаешь окна растянутые на 2 экрана?
А старый софт видимо тупо залочат под коэффициент того моника, на котором его запустили. И хоть затаскайся.
Ну кстати х.з. почему в прыщах не сделали. Пишут что GTK под вендой вполне так обрабатывает эти сообщения. Qt скорее всего тоже умеет. Т.е. основные фрейморки к этому готовы.
dpi завезли в xrandr, но и там он кажется что сделан поверх фейкования размера экрана. В общем мрак, говно, и 1989-й год.
Может, в вейленде пофиксят
В иксах вроде даже свой юникод был (или даже сейчас есть?)
"Не дай бог мне иметь дело с виндой на сервере
Не дай бог мне иметь дело с линуксами на декстопе" (С)
Хотя конкретно тут соснул скорее Xorg, а вернее даже X11, а он всё же не прыщи. Так что соснули все юниксбляди
32:9 не хочешь? https://www.lg.com/ru/monitors/lg-49WL95C-W
Вон на картинке даже тебе нарисовали видеоредактор.
Ещё видел, такие используются у диспетчеров. Везде, короче, где есть какая-то колбаса из дорожек или схем.
Я б не отказался от такого. Но цена космос
Но, в целом, для игр 2 моника удобнее получается - один в эксклюзивном режиме под игру чтобы десктоп свои тормоза не вносил, второй под какие-нибудь чатики или доки. И не надо пердолиться с растягиванием и положением окна, как это пришлось бы делать на одном большом.
Правда, у меня сейчас и двух мониторов-то нет, плак-плак
Интересно, а бывает смулятор маршрутки?
Или наоборот: человек работает машинистом, а в свободное время играет в симулятор программирования
балуется с пхп-фреймворками?
https://youtu.be/TxbvArIqskg?t=15
Симулятор козла!
Симулятор программирования тоже есть, посмотри на игры Zachtronics.
> у меня нету хобби.
- чо так?
Называется оный симулятор «Desert Bus».
Драйвовая штука. Очень рекомендую.
А кто-то делит один монитор с соседом по комнате.
А программирую на листочке, и ношу потом его на работу, и там ввожу в комп
Ну или в тетрис играть.
Коллеги потом читают на моне 4:3, и тупят
Всё-таки люди потеряли чувство прекрасного.
Эпоха Возрождения. Золотое сечение.
А что теперь? Всё засрато т.н. «cовременным искусством». «Пирфомансы», «инсталяции», «каляки-маляки» сплошные «танковые щели».
Сразу видно - настоящие Олимпиадники!
Хотя не, тут макаки какие-то писали.
На строке
наблюдаем:
request - это чуть выше
ton::http::HttpRequest это вот там
т.е. да, это std::string
Наверное, со времён «ВК» и «Телеграма» дуровские о-лим-пи-ад-ни-ки выросли, стали тимлидами и проджект менеджерами, наняли скриптомакак и теперь командуют им пилить велосипеды с нуля, как на о-лим-пи-а-дах.
Блядь, ну и дерьмо. У них руки что ли отваливались, так лень было пару тайпдефов сделать?
Кстати забавно, что в сишке я мог сказать strncmp(host, "http://", 7). А в крестах удобных и эффективных аналогов тупо нет.
string_view только с с++17.
starts_with только с с++20.
Можно, конечно, std::mismatch() позвать если с++14 и выше и он даже итератор на первый символ за http:// вернёт. Но до с++14 то что делать?
Крестобляди соснули )))
Да, они очень обобщённые и каждый отвечает за что-то одно. Но когда на практике начинаешь их юзать, получается пиздец в духе:
В этом и проблема: чтобы пользоваться крестами, а не дрочить .begin() .end() .begin() .end() до посинения, тебе придётся постоянно намазывать высокоуровневый API. Потом тебя это заебёт, и ты вынесешь его в отдельную либу «util». Потом тебя заебёт ебля с линковкой и ты сделаешь её header-only. Потом ты решишь поделиться своим творением, переименуешь его в «Boost» и зальёшь в какой-нибудь «Github».
Либо ты просто выкинешь нахуй «STL» и запилишь свою стандартную либу: реальные примеры я недавно приводил: «EASTL», «folly», «abseil» — тысячи их.
Блин, ну сравнил boost и какую-то сраную гуаву.
boost реально стоит половины гавеновского репозитория в жабе или десятка апачевских либ (а не только commons).
А npmy с его isTen до возможностей буста срать и срать.
Ну по сути верно. Без буста, в крестах довольно трудно, особенно в старых стандартах. Как и в жабе без ломбоков, гуав и прочей питушни.
У pethu всего одиннадцать пакетов. Хочу is-eq-forty-two.
https://www.npmjs.com/~pethu
Смотрю на эту зловонную срань, и понимаю что не зря америкосы Пашу озалупили на взлёте. Ох не зря.
Пацан к успеху шёл.
> Как устроен парсер? Мы, как nginx, определяем массив байт и по нему
Золотые, бессмертные строки Царя как нельзя лучше подходят к моменту.
Какие нодыжс - ты упорлся - это бездарное говно от питухов для питухов. Нормальных вебсерверов не существует. Есть более-мене нормальные, аля http://gwan.ch - ты не смотри там на названия эзыков, а тыкай по ссылки и читай.
Причём тут жс, флеш и прочее - всё это говно, а хтмл тормазит именно сеть и питушит сервера.
Нормальный - я тебе описал. Ты, никакие хттп запросы руками не пишешь - я тебе описал пример с опкодами.
Вместо данных - юзай хтмл, если питух. Юзай бинарь, если не питух. Передавай код на сишке, который будет бутстрапица у тебя в броузёрке и рисовать твой сайтец на опенгл"е, общатся по нормальному сокету и никаких хтмл не нужны вообще.
https://govnokod.ru/13420#comment188632
А знаешь, сколько реквестов будет выдавать нормальные бинарные заголовки? И данные, как гзипованный хваст?
Суть в том, что люди изначально придумывают говно, а потом пишут мегобыстрые парсеры, хренансеры - хотя проще изначально выпилить текст и не юзать его нигде.
Потом пишут валидирующие парсеры, ибо "мы питушки не знаем, где мы не ту букву поставили" - это ещё -50% перфоманса, вплоть до -98%.
Я конечно понимаю, что героически решить проблему, которую сами же создали - аля: 10k rps problem. Тцп стек уже лет 100 как 10кrps умеет. Неумело этого: Питушарское хттп, хтмл и прочее говно - но у нас появились процессоры и мы написали омегабыстрые парсеры и добились своих 10krps в лучше случае, и то на статике.
А сейчас нормальный "вебсервер", не то говно, аля нгинкс, апач и прочее - именно парсер опкодов и раскидывателей данных - выдаёт тысячи тонн rps. В тысячи раз больше, чем самый илитный веб. Как так?
Заголовок к нормальном протоколе - это опкод и его стрктура. Это парсится процессором на скорости близкой к терабайту в секунду максимум - ну 100гигов дастс даже в самом слабом случае с тысячей переходов. Т.е. на порядки быстрее ущербанского гигабита.
Сравни это с ущербанским вебом. Кому нежен этот питушарних html, хмл и иные реализации этого говна? Выпили это говно - запили нормальное бинарное представление. Сразу будет буст на порядки - нет, мы питухи - мы юзаем говно, гинерим говно и рисуем говно. Мы хвалимся тем, что мы хоть что-то сделали и оно работает.
напишите нормальный клиент на плюсах под API конкретной операционки и сервер на них же, и протоколом бинарный: тупо гоняйте структурки правильно выравненные и с правильным байтордером.
И ваше приложение будет в пиздилион раз быстрее и меньше весить, чем клиент на жопаскрипте в хроме и сервер на апаче
Гавноеды ебучие сначала шлют контент джейсоном в base шесятчетыре, а потом чото там "оптимизируют"
Идите двойные кавычки на одинарные поменяйте в пхп, оптимизаторы мамиеы
> Идите двойные кавычки на одинарные поменяйте в пхп, оптимизаторы мамиеы
сука я аж хрюкнул