The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Cloudflare перешёл с NGINX на прокcи Pingora, написанный на языке Rust, opennews (??), 16-Сен-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


228. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +1 +/
Сообщение от Ivan_83 (ok), 16-Сен-22, 21:53 
Сказки смузихлёбов: думать нинада, только смузи и сыры, раст сам всё сделает.

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


> Нет, что произошло -- системное программирование стало настолько простым

Потому что период активного изменения АПИ закончен как в линухе так и в бсд, и есть куча актуальной документации и либ, накопленные за 20 лет.


> Мы идём к светлому будущему, в котором full-stack будет начинаться с verilog, простираться через написание собственной ОС под собственный чип, и заканчиваться конкретным юзерспейс софтом.

Нет, не идёте, вы грезите :)

Ответить | Правка | Наверх | Cообщить модератору

236. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/
Сообщение от Аноним (236), 16-Сен-22, 23:10 
> В С ты тоже берёшь нужную тебе либу с нужной моделью асинхронности, либу которая будет тебе парсить что захочешь и вот у тебя сервер.

Да неужели? В новости описываются две разные модели. Ты можешь назвать две библиотеки, из которых одна реализует одну из моделей, а другая другую?

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

Открой для себя cargo tree. Там все библиотеки расписаны. Да, если ты пишешь http сервер их там будет пара сотен на старте. Но видишь ли, прочитать список пакетов из двух сотен и поинтересоваться зачем каждый из них нужен -- это развлечений ну на день отсилы. На самом деле меньше, потому что про половину или даже большую часть ты и так знаешь. А когда ты интеллектуально капитулируешь, говоря "вообще ничего не понятно", ты обрекаешь себя на написание всей функциональности этих крейтов. Развлечений на пару-тройку лет. Это если на расте писать, на C ты это будешь писать и отлаживать лет десять.

Этот список пакетов столь же "непонятен" как и 200 .c сорцов из какого-нибудь монолита на C. Он вызывает те же самые чувства при первом взгляде. Совершенно нормально не понимать, как устроена и работает большая и сложная система. Даже прям скажем ненормально понимать с первого взгляда как она работает. Это одолевается тем же путём: вешаешь на стену лист A0, берёшь маркер и начинаешь на нём рисовать "файлы", их краткое описание (которое ты сочиняешь, читая сорцы), кросс-депендансы, и тп. Через неделю ты уже неплохо ориентируешься в коде, и готов приступать к конкретной задаче, ради которой ты затеял изучение этого кода.

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

> Потому что период активного изменения АПИ закончен как в линухе так и в бсд, и есть куча актуальной документации и либ, накопленные за 20 лет.

Да-да. Мир такой, какой он есть, и он никогда не изменится. Ты знаешь сколько поколений до тебя верили в эту сказку? Почему-то чем дольше что-то продолжается по времени, тем сильнее люди верят в то, что оно вечно. Хотя ровно наоборот: чем дольше стоит, тем глубже прогнило, и тем ближе время, когда оно рухнет. Как только способность меняться утеряна (а она утеряна полностью через 10 лет после последних крупных изменений), так сразу начинается необратимый процесс гниения.

Бывают ситуации, в которых сложно понять можно ли текущие изменения называть крупными и свидетельствующими о способности меняться под меняющийся мир. Но это явно не про системное программирование на C.

> Нет, не идёте, вы грезите :)

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

Ответить | Правка | Наверх | Cообщить модератору

247. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/
Сообщение от Ivan_83 (ok), 17-Сен-22, 02:29 
Я не большой знаток либ, я велосипедостроитель.
libev/libevent реализуют модель подобную той что в nginx.
Библиотек реализующих модель клауда я не знаю, потому что не интересовался.


> Открой для себя cargo tree. Там все библиотеки расписаны.

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


> Да-да. Мир такой, какой он есть, и он никогда не изменится.

kqueue(), epoll() - лет 20, poll(), select() - сильно больше.
За последние лет 10 там завезли немного флагов, для kqueue() зввезли работу с какими то подсистемами.

Насколько я видел, даже возможности epoll() почти нигде не раскрыты целиком, а уж возможности kqueue() вообще используются на минималках.

И в целом там особо ничего нечего улучшать.
Можно сходить по пути МС с их портом завершения в/в, но там свои минусы есть, в нынешних реалиях, особенно линукса, оно скорее ухудьшит производительность в сравнении с тем что поверх epoll() можно нагородить.


> Естественно. Ясновидение это всегда грёзы. Но ты сам понаблюдай, и ты увидишь.

Вы обычный фонатик раста, который о системном программировании мало что знает.

Ответить | Правка | Наверх | Cообщить модератору

255. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/
Сообщение от Аноним (-), 17-Сен-22, 05:28 
> Я не большой знаток либ,

Откуда тогда наглости набрал врать про то, что под любую модель можно найти библиотеку?

> libev/libevent реализуют модель подобную той что в nginx.

Это ведь форки древнего libpth, я правильно помню? И где их используют? Хоть один продакшн реди проект на них есть?

> kqueue(), epoll() - лет 20, poll(), select() - сильно больше.

О, это ядрёные API, которые всё равно в большинстве случаев требуют оберток, чтобы их можно было бы эффективно использовать. Это как с read/write, которые для большинства применений невыносимо тормозны без юзерспейс буфера. Но, каким бы ты не был велосипедостроителем, ты же не велосипедишь каждый раз аналог stdio.h?

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

> Вы обычный фонатик раста, который о системном программировании мало что знает.

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

Ответить | Правка | Наверх | Cообщить модератору

303. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/
Сообщение от Ivan_83 (ok), 17-Сен-22, 15:04 
> Откуда тогда наглости набрал врать про то, что под любую модель можно найти библиотеку?

Наверное можно, или написать самому.


> Это ведь форки древнего libpth, я правильно помню? И где их используют? Хоть один продакшн реди проект на них есть?

libpth - впервые слышу.
libevent - фаерфокс и хромиум, turnserver, prosody, unbound
libev - ничего не нашлось из того что у меня установлено.


> О, это ядрёные API,

Ядерные API это KAPI, и используются они для общения модулей внутри ядра.


> в большинстве случаев требуют оберток, чтобы их можно было бы эффективно использовать

Зависит от задачи.
У меня для glib файловый мониторинг сделан на kqueue(), никаких обёрток особо не потребовалось.
Но в целом да, это низкоуровневое решение и сразу буизнес логику поверх kqueue()/epoll() писать нельзя, это не недостаток, просто оно так устроено.


> Это как с read/write, которые для большинства применений невыносимо тормозны без юзерспейс буфера.

Так только дебило-джун будет читать по одному байту в цикле, даже не знаю зачем вы пишите такую банальщину.


> ты же не велосипедишь каждый раз аналог stdio.h

Нет.
Я читаю/пишу либо файл целиком либо кусками хотя бы по 512кб.


> Плюс они часто системно-зависимы и велосипеды приходится оснащать костылями для портабельности. Кому это нужно? Только мамкиным велосипедостроителям.

Я пишу под фрю, и иногда проверяю что на линухе тоже работает, остальная портабельность мне не интересна.
И нет, мне не так трудно поддерживать её самому.

> Это даст тебе моральное право ещё десять лет игнорировать изменения мира и жить в своём виртуальном мирке.

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

У меня же своя libev/libevent, я взял и написал обёртку над kqueue() и epoll() которая позволяет писать переносимый код между бсд и линухом, и как пример там msd, ssdpd приложения есть.
Я прошёлся по всем граблям в обеих ОС.
Это и есть системное программирование про которые растбои кричат, а не вот этот ваш раст запускать.

Прикол в том, что даже Visual Basic ещё есть вакансии, а для С програмистов ваканский куча, мне работы точно хватит до смерти :)
И да, я не продаю знание языка С, я продаю знание технологий, просто я в основном на С общаюсь с компом, и это удобно, потому что все ОС на нём написаны.
А вы фонатеете по языку, знание которого бесполезно если вам нечего на нём писать.

Ответить | Правка | Наверх | Cообщить модератору

318. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/
Сообщение от Аноним (-), 17-Сен-22, 16:42 
> Наверное можно,

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

> или написать самому.

На то, чтобы реализовать гринтреды в той модели, которая тебе нужна, с пулом потоков, с очередью задач, и прочим, тебе потребуется полгода. Год, если кроссплатформенно и оптимизировано на основе профайла под высокой нагрузкой. И ещё полгода и сотня тысяч баксов за внешний аудит твоего кода.

> libevent - фаерфокс и хромиум, turnserver, prosody, unbound

Я удивлён. C'шники они как правило велосипедисты, и готовы затянуть разработку на два лишних года, лишь бы не использовать депендансы. С другой стороны, фф с хромом это не C'шники, это C++. Эти чуть менее склонны велосипедить.

> Я читаю/пишу либо файл целиком либо кусками хотя бы по 512кб.

То есть велосипедишь буферизированный ввод вывод? Как ты парсишь http в таком варианте? Вот распарсил ты "Accept-En", и буфер кончился, дальше ты копируешь Accept-En в начало буфера, и заказываешь чтение на хвост буфера? Ну-ну. Прикинь я из std получаю функцию readline, которая все эти штуки делает самостоятельно.

> Я пишу под фрю, и иногда проверяю что на линухе тоже работает, остальная портабельность мне не интересна.

А вот большинству системных программистов интересна. Им интересно чтобы, в первую очередь, стабильно работало на linux'е, во-вторую очередь на bsd, в-третью очередь на прочих unix'ах, и для некоторых проектов ещё важна венда. И что ещё интереснее, часто неизвестно заранее, что из этого списка потребуется после.

Не надо свой специальный случай распространять на всё системное программирование.

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

1. Если я использую либы, это не значит, что я не понимаю как эти либы работают.

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

> Прикол в том, что даже Visual Basic ещё есть вакансии, а для С програмистов ваканский куча, мне работы точно хватит до смерти :)

Хватит. И чё ты тогда в комментах развоевался?

> И да, я не продаю знание языка С, я продаю знание технологий,

Хаха. "Знание технологий". Если ты велосипедишь без уважительной причины, то это не "знание технологий", это "знание теории". Оторванность от практики уровня профессора расеянского вуза.

Ответить | Правка | Наверх | Cообщить модератору

338. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/
Сообщение от Ivan_83 (ok), 18-Сен-22, 03:36 
Когда нечего сказать надо докопатся по пацански, да?


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

Дорогой джун, это ваши фантазии :)
Как минимум профайлинг там вообще ни разу не упал, вы бы это знали, если бы хоть раз что то сами писали.
Насчёт реализаии я подумаю.


> То есть велосипедишь буферизированный ввод вывод? Как ты парсишь http в таком варианте? Вот распарсил ты "Accept-En", и буфер кончился, дальше ты копируешь Accept-En в начало буфера, и заказываешь чтение на хвост буфера? Ну-ну. Прикинь я из std получаю функцию readline, которая все эти штуки делает самостоятельно.

https://github.com/rozhuk-im/liblcb/blob/master/src/proto/ht...
вот так я это делаю.
В начале надо поймать crlfcrlf - маркер окончания заголовка, а уже потом парсить.
Ни std ни readline я не юзаю - нету в них смысла. Это инструменты уровня консольных утилит, чтобы по быстрому накодить приложуху которая работает меньше секунды и завершается.
А проблемы с внезаптным концом данных при парсинге - это детский сад, который у меня был в 2003 году.
Те вы мало того что пытаетесь мне сообщить о важности мытия рук перед едой, о которой сами недавно узнали, так ещё и не дошли до стадии что руки надо мыть с мылом - те парсить когда весь заголовок приедет.
Осталось дождаться когда вы сделаете важное открытие, что оказывается заголовок парсить не всегда нужно, а когда нужно, но это будет через пару лет, вы узнаете что там есть проверки валидности пришедшего согласно RFC.


> А вот большинству системных программистов интересна. Им интересно чтобы, в первую очередь, стабильно работало на linux'е, во-вторую очередь на bsd, в-третью очередь на прочих unix'ах, и для некоторых проектов ещё важна венда.

Какому большинству!?
Вашим двум однокурсникам?
Почему меня это должно волновать?
Чтобы вы знали, nginx на линухе поддерживается и пилится по такому же остаточному принципу, по крайней мере долгое время так было. И все новые фрёвые фичи даже с каррента уже юзаются в нгинхе.

> 1. Если я использую либы, это не значит, что я не понимаю как эти либы работают.
> 2. Мне нет нужды доказывать кому-то, что я понимаю как реализуются гринтреды посредством написания велосипеда гринтредов.

Ты палишься как зелёный джун в каждом посте, куда уж больше :)
Это я к тому что ты там собрался профилировать обвязку над kqueue()/epoll() - это просто дичь.
Хотя что взять с человека который обмазывается либами которые работают неведомым ему образом, ты же пихнёшь в обвязку чтото что тебе кажется простым а потом будешь с профайлером искать чего оно так тормозит. У крестовиков такое постоянно происходит: вроде написана очевидная штука а оказывается что она жестоко грузит проц ненужными действиями.

Я вот когда пользую ffmpeg, OpenCV - даже не стесняюсь признавать что я не понимаю как они работают, там тонны математики и десятки тысяч человеко/часов.


> Хаха. "Знание технологий". Если ты велосипедишь без уважительной причины, то это не "знание технологий", это "знание теории". Оторванность от практики уровня профессора расеянского вуза.

Звучит как будто вы с урока в туалет отпрашиваетесь - всё бы вам уважительные причины :)

Речь шла именно про знанение технологий с которыми работаешь.
Пока вы там со своим буферезированным std будете файл с диска по хттп отдавать перекладывая в сокет, я возьму sendfile(), и для tls приколхожу ядерную реализацию чтобы ядро само всё делало, по возможности используя аппаратный акселератор в железе.
Ну и фишка в том, что у меня msd проксирует потоки, и он тоже испольует sendfile() вместо обычного send(), тем самым экономя проц на копировании данных с юзерспейса в ядро, потому что в кольцевой буфер только один источник записи но потенциально куча читателей.
Этого всего нет и не будет ни в каких библиотеках, никаких растах.
Это именно низкоуровневый кодинг с использованием всех доступных фич ОС.
Так же как на линуксах делают магию со splice, каждый раз отдельно под каждую задачу.

Ну или упомянутые выше OpenCV - что вы там со своим знанием раста сделаете?
Соберёте тестовый пример?
OpenCV сам по себе "язык" по круче раста для работы с изображениями и видео, пофик с какого языка ты её юзаешь.

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

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

Правда имплементировать крипту мне нравится, я даже свою реализацию ECDSA сделал с нуля на С.
Там и математика полностью своя.
Можешь падать в обморок или бится истерике: С, криптография и не дипломированный специалист в области крипты в одном  решении сошлись.


Надо ради прикола в ваш раст своего С кода понакомитить, по больше, чтобы он помер по быстрее :))))

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру