С какой IDE, причем тут IDE, зачем вообще IDE? Системы сборки всегда стараются делать как раз НЕ зависимыми от конкретного языка. Причем тут низкоуровневой SDL, который надо сравнивать скорее с libxcb или Win32 API, нежели высокоуровневым Qt, для которого тоже полно альтернатив "почти везде", хоть GTK, хоть Tcl/Tk ? В общем, коммент из сугубо узкой личной ниши.
Зато трафик может сэкономить. Во всяком случае, можно выложить две версии - решение исторических костылей веба в виде одного .html для тупого быдла и .zip для тех, кто понимает, и экономит трафик.
И кстати, & бы тоже убрать для надежности, да и на все <33 тоже полагаться - ну такое себе, мало ли кто испортит документ по пробельным символам/переводам строк (да, включая табы).
Та транзакция, которая в банковском смысле - она совсем не равна транзакции в БД или даже количеству строк. Для одной банковской транзакции делается очень много SQL-запросов, причем на разных системах, так что нет, сотни тысяч в секунду тут попросту невозможны.
Про IoT отдельно посмеялся - это жирный-то QUIC туда совать, который не просто DoS легко устроить, но даже MTU меньше 1200 не поддерживает? Когда в типичном IoT в десять раз меньше, и специальные протоколы применяют, даже старый HTTP слишком сложен и жруч.
И нет, за пределами HTTP у него так и не появится много применений - модель потоков слишком тупая.
Режим UDP-туннеля и DTLS для SCTP были стандартизированы еще перед тем, как начали SPDY - у туннеля стандартный порт 9899, это сто лет есть в референсной (FreeBSD) имплементации. Причины чуть-чуть в другом, см. соседний коммент.
Две большие причины. Во-первых, SCTP делался телефонистами. То есть, например, до введения чанков I-DATA в примерно 2017 (SPDY потребность делать возникла раньше) страдал от того же Head-of-Line blocking - если сообщения были размером больше сетевого пакета (а в телефонии обычно маленькие). И кроме того, поскольку опять же делался телефонистами, они там не предусмотрели еще нескольких вещей, от которых generic-приложения бы неплохо выиграли - хотя бы нет приоритетов потоков, нет раздельных окон для потоков (это уже мало кому надо, но всё же).
Во-вторых, Гуглу нужна монополия, но не бросающаяся в глаза, и удобнее всего её достигать, когда контролируешь обе стороны имплементации - для чего сначала спонсировали Let's Encrypt с повальным переходом на HTTPS (совершенно не нужным массово), а позже удобно иметь собственный протокол с собственными расширениями в собственном браузере. Стандартизирована-то только совсем базовая версия QUIC.
Нет. Нету раздельного приёмного окна для каждого потока, значит, ты говоришь о чём-то другом, но не том, что я имею в виду.
Ну, в данном контексте речь шла о HOL Blocking, когда один поток большим сообщением блокирует остальные - вот эта проблема ими пофикшена. А то, что хочешь ты, это за рамками модели SCTP (и в т.ч. поэтому я начал придумывать muSCTP).
И он будет означать только то, что что-то услышано, но не что данные приняты - это если в пакете были чанки нескольких потоков, из которых из одного данные приняты, а другого - нет, потому что окна нету. Увы.
Почему же, TSN назначается на чанк, а не пакет, поэтому в том виде, каком ты хочешь (за рамками модели SCTP), чанки из непринятого просто стали бы gaps в SACK. Или же можно ввести NACK (у меня он пока только для случаев фейлов PPP compression), точнее, что-то да надо, потому что congestion control должен понимать, что пакет не потерян. Но дублировать по SACK'у на каждый стрим мне видится чрезмерно избыточным на low bandwidth high latency, когда стримов много. Впрочем, я вообще красивого решения пока не нашел - функционал SACK'ов как уровнем выше пересекается с отсылкой инфу о векторе пакетов (ECN, дубликаты) на каждом Path. Опять же, проблема общего окна нескольких стримов при borrow...
TIMTOWTDI. Родившаяся (сюрпрайз) как раз в языке Perl и делающая невозможным совместные единообразные действия гетерогенной команды без перманентных срачей.
Вот это, собственно, и есть байки. Нет, я понимаю, в конце 90-х могло не повезти с проектом (какая-нибудь дичь типа SpamAssassin или подобных на 70 тыщ строк в одном файле - вполне создавали репутацию). Но дальше, в нулевых и тем более в десятых, в коммерческих проектах я видел вполне себе читаемый поддерживаемый код (а перевидал я их немало).
Более того, взявшись этим летом изучать Питон, я охренел от такого количества нелогичностей, и даже хохотал именно от случаев TIMTOWTDI. Не, у каждого языка есть свои заморочки, но не позволительно как раз тому, кто назвался "есть только один способ сделать это", причем пригодным для обучения новичков. Вот им лучше мозги гвидобейсиком не портить. Ну например, сколько у них способов отформатировать строку? Пять? А в Перле только один - sprintf (не считая format'ов, объявленных устаревшими еще в 90-е). Что очевидного и не write-only в бидоновой конструкции [::-1] ? Функция len() и методы с кучей двойных подчеркиваний - и эти люди говорят о читабельности, Карл! - это отдельный цирк. Почему-то как раз в Перле всё это просто и логично, несмотря на декларируемый TIMTOWTDI ?
В общем, почитав книгу по Питону, особенно в местах про замыкания и scoping, у меня сложилось впечатление - потому что Перл делали умные люди, а Гвидо недоучка.
ругань команды пайтонистов на мой перловый код (именно этими словами) слышал не раз.
Соответственно с учетом вышесказанного, мнение этих быдлокодеров я вообще не стал бы принимать во внимание.
Парадокс, но именно богатство языка - его же и убивало
Забавно звучит в контексте очень толстой стандартной либы Питона, при том, что в Перле встроенных функций всего 300 с копейками. Нет, убивало язык на самом деле - писание Perl 6, типа всего такого "перепишем с нуля щас", классической ошибки - т.е. неясные перспективы. А питон в это время зашел в учбеные/научные учреждения, естественно те потащили потом его с собой дальше. Разгадка примерно того же рода, почему Microsoft попустительствовал пиратским копиям своего софта долгое время.
Представляете, в системах управления ракет в году так примерно 1950-м какие только не решали вещи аналоговыми элементами - вплоть до моделирования химическими процессами. Восхититься можно, как умели, и без всякой цифры (за отсутствием таковой).
С какой IDE, причем тут IDE, зачем вообще IDE? Системы сборки всегда стараются делать как раз НЕ зависимыми от конкретного языка. Причем тут низкоуровневой SDL, который надо сравнивать скорее с libxcb или Win32 API, нежели высокоуровневым Qt, для которого тоже полно альтернатив "почти везде", хоть GTK, хоть Tcl/Tk ? В общем, коммент из сугубо узкой личной ниши.
Так это претензии к системам сборки - они все неадекватные какие-то. А на Qt тоже свет клином не сошелся.
Зато трафик может сэкономить. Во всяком случае, можно выложить две версии - решение исторических костылей веба в виде одного .html
для тупого быдлаи .zip для тех, кто понимает, и экономит трафик.И кстати, & бы тоже убрать для надежности, да и на все <33 тоже полагаться - ну такое себе, мало ли кто испортит документ по пробельным символам/переводам строк (да, включая табы).
А просто, как в старые добрые времена, отдать .zip-файл, в котором надо кликнуть index.html?
Та транзакция, которая в банковском смысле - она совсем не равна транзакции в БД или даже количеству строк. Для одной банковской транзакции делается очень много SQL-запросов, причем на разных системах, так что нет, сотни тысяч в секунду тут попросту невозможны.
Тогда банили только сами такие клиенты, а не весь аккаунт.
Дык я и сказал - не нужным массово. А что интересы Гугла противоречат интересам широких пользовательских масс, это уже другое дело.
Ну а Скрипач тут разве что в виде побочки для обхода DPI.
Про IoT отдельно посмеялся - это жирный-то QUIC туда совать, который не просто DoS легко устроить, но даже MTU меньше 1200 не поддерживает? Когда в типичном IoT в десять раз меньше, и специальные протоколы применяют, даже старый HTTP слишком сложен и жруч.
И нет, за пределами HTTP у него так и не появится много применений - модель потоков слишком тупая.
...которую очень дешёво решал Keep-Alive нескольких параллельных соединений. Не идеально, но роль QUIC тут сильно преувеличена.
...при этом режим 0-RTT не рекомендован как имеющий проблемы с собственно безопасностью
...при этом стандартизирована только базовая версия QUIC, а не проприетарные расширения Гугла.
Режим UDP-туннеля и DTLS для SCTP были стандартизированы еще перед тем, как начали SPDY - у туннеля стандартный порт 9899, это сто лет есть в референсной (FreeBSD) имплементации. Причины чуть-чуть в другом, см. соседний коммент.
Две большие причины. Во-первых, SCTP делался телефонистами. То есть, например, до введения чанков I-DATA в примерно 2017 (SPDY потребность делать возникла раньше) страдал от того же Head-of-Line blocking - если сообщения были размером больше сетевого пакета (а в телефонии обычно маленькие). И кроме того, поскольку опять же делался телефонистами, они там не предусмотрели еще нескольких вещей, от которых generic-приложения бы неплохо выиграли - хотя бы нет приоритетов потоков, нет раздельных окон для потоков (это уже мало кому надо, но всё же).
Во-вторых, Гуглу нужна монополия, но не бросающаяся в глаза, и удобнее всего её достигать, когда контролируешь обе стороны имплементации - для чего сначала спонсировали Let's Encrypt с повальным переходом на HTTPS (совершенно не нужным массово), а позже удобно иметь собственный протокол с собственными расширениями в собственном браузере. Стандартизирована-то только совсем базовая версия QUIC.
Конечно гугл виноват - UDP блокировался много где и до эпохи DPI. По чисто техническим проблемам оборудования, в том числе.
Ну, в данном контексте речь шла о HOL Blocking, когда один поток большим сообщением блокирует остальные - вот эта проблема ими пофикшена. А то, что хочешь ты, это за рамками модели SCTP (и в т.ч. поэтому я начал придумывать muSCTP).
Почему же, TSN назначается на чанк, а не пакет, поэтому в том виде, каком ты хочешь (за рамками модели SCTP), чанки из непринятого просто стали бы gaps в SACK. Или же можно ввести NACK (у меня он пока только для случаев фейлов PPP compression), точнее, что-то да надо, потому что congestion control должен понимать, что пакет не потерян. Но дублировать по SACK'у на каждый стрим мне видится чрезмерно избыточным на low bandwidth high latency, когда стримов много. Впрочем, я вообще красивого решения пока не нашел - функционал SACK'ов как уровнем выше пересекается с отсылкой инфу о векторе пакетов (ECN, дубликаты) на каждом Path. Опять же, проблема общего окна нескольких стримов при borrow...
Вот это, собственно, и есть байки. Нет, я понимаю, в конце 90-х могло не повезти с проектом (какая-нибудь дичь типа SpamAssassin или подобных на 70 тыщ строк в одном файле - вполне создавали репутацию). Но дальше, в нулевых и тем более в десятых, в коммерческих проектах я видел вполне себе читаемый поддерживаемый код (а перевидал я их немало).
Более того, взявшись этим летом изучать Питон, я охренел от такого количества нелогичностей, и даже хохотал именно от случаев TIMTOWTDI. Не, у каждого языка есть свои заморочки, но не позволительно как раз тому, кто назвался "есть только один способ сделать это", причем пригодным для обучения новичков. Вот им лучше мозги гвидобейсиком не портить. Ну например, сколько у них способов отформатировать строку? Пять? А в Перле только один - sprintf (не считая format'ов, объявленных устаревшими еще в 90-е). Что очевидного и не write-only в бидоновой конструкции [::-1] ? Функция len() и методы с кучей двойных подчеркиваний - и эти люди говорят о читабельности, Карл! - это отдельный цирк. Почему-то как раз в Перле всё это просто и логично, несмотря на декларируемый TIMTOWTDI ?
В общем, почитав книгу по Питону, особенно в местах про замыкания и scoping, у меня сложилось впечатление - потому что Перл делали умные люди, а Гвидо недоучка.
Соответственно с учетом вышесказанного, мнение этих быдлокодеров я вообще не стал бы принимать во внимание.
Забавно звучит в контексте очень толстой стандартной либы Питона, при том, что в Перле встроенных функций всего 300 с копейками. Нет, убивало язык на самом деле - писание Perl 6, типа всего такого "перепишем с нуля щас", классической ошибки - т.е. неясные перспективы. А питон в это время зашел в учбеные/научные учреждения, естественно те потащили потом его с собой дальше. Разгадка примерно того же рода, почему Microsoft попустительствовал пиратским копиям своего софта долгое время.
Откуда берутся эти пересказыватели баек..
Они на подобных чипах и делаются, собственно.
Потому что нафиг не нужны и историческая ошибка.
Между баблом и чистым познанием большой спектр есть, они прекрасно могли себе писать книги, и писали же.
Представляете, в системах управления ракет в году так примерно 1950-м какие только не решали вещи аналоговыми элементами - вплоть до моделирования химическими процессами. Восхититься можно, как умели, и без всякой цифры (за отсутствием таковой).