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

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

Ну тогда демон с локальным сокетом, да. Сеть ему не нужна.

что проще - развернуть нттп на си или сокет на пхп?

Очевидно, второе.

спасибо, попробую.

Поставь nginx, а на с напиши fastcgi. И будет тебе счастье

уже стоит, как без этого.

Тогда на кой черт секс с пыхпыхом?

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

Ну будь готов к тому, что веб на CURL — ад и дырявый израиль. То есть реально безопаснее FCGI сделать, и разве что не руками HTTP хидеры писать.

в хидерах ниче сложного нету, составлял и парсил. я категорически против курла - это чистое зло, он создан для страданий.

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

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

в хидерах ниче сложного нету, составлял и парсил. я категорически против курла - это чистое зло, он создан для страданий.

Это пока на той стороне вебсокеты (протокол поверх HTTP) не сделают. Вот серьезно, я бы на твоем месте хотя бы попробовал Go для сетевой части. Очень может быть, что тебя язык устроит. А вычисления делай на C.

я категорически против курла - это чистое зло, он создан для страданий.

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

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

Сложный код — хрен с ним. Почему там CVE каждый месяц находят? И зачем там SMTP?

где там «CVE каждый месяц»? у тебя какая-то паранойя насчёт CVE.

Выше ссылка. Почти каждый месяц отмечен новым CVE.

Вот, сюда вставлю: https://curl.haxx.se/docs/security.html

и где там «каждый месяц»? и если ты почитаешь, про что там, то там ничего опасного нет. если код писать аккуратно.

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

и где там «каждый месяц»?

Ну ссылку открой, лол. В феврале три штуки. Потом три месяца перерыв, и пошло-поехало: октябрь, сентябрь, июль, май, март (несколько штук), январь.

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

Там переполнения буферов, стека и integer overflow (один из самых опасных UB). Это, по-твоему, «ничего опасного»? :)

P.S. В нем еще auth leak недавно нашли, который там чуть ли не с первого коммита был.

и что? несущественные баги в протоколах типа ntlm тебя так пугают? меня они вообще не колышут.

я так понимаю, они там начали шерстить код, который никогда не использовался.

и что? несущественные баги в протоколах типа ntlm тебя так пугают? меня они вообще не колышут.

Во-первых, если в библиотеке регулярно находят проблемы с памятью — у нее отвратный Q&A. И еще автор пишет небрежно. Это не внушает доверия.

Во-вторых, куда же подевались твои «хорошие программисты не допускают проблем с памятью»?

В-третьих, баги там везде, не то только в NTLM. Самый эпичный за этот год:

curl might leak authentication data to third parties.

When asked to send custom headers in its HTTP requests, curl will send that set of headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

Sending the same set of headers to subsequent hosts is in particular a problem for applications that pass on custom Authorization: headers, as this header often contains privacy sensitive information or data that could allow others to impersonate the curl-using client's request.

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

ну, если у тебя аутентификация шлётся по http и открытым текстом - то ты ссзб. потому что и без курла можно перехватить такой трафик. а https ты не средиректишь куда попало.

так что паника, собственно, не к месту.

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

Господи, «дыры — это не дыры, если в моем любимом проекте»? Серьезно? Взрослая же тетя вроде.

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

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

быстро
баг был с момента первого коммита

Ну лал же.

А, вот смотри еще что в январе нашли:

libcurl contains an out bounds read in code handling HTTP/2 trailers.

It was reported that reading an HTTP/2 trailer could mess up future trailers since the stored size was one byte less than required.

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

Безусловно. Только вот реализация на Go от таких грехов не страдает. Так почему же не взять хороший инструмент вместо бажного?

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

Только вот реализация на Go от таких грехов не страдает. Так почему же не взять хороший инструмент вместо бажного?

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

И чё?

Уязвимости в пользюковской либе. Ну и заломайте теперь с их помощью сервак, где libcurl может в принципе не быть, а будет например, libevent, на основе которой написаны микросервисы, которые крутятся на данном серваке? Вперёд! =)))

Здесь эти уязвимости что есть, что нет. Ну плохо, да. Но не фатально.

Если бы эти уязвимости были здесь (https://www.cvedetails.com/vulnerability-list/vendor_id-15590/product_id-32303/Libevent-Project-Libevent.html), то я бы да, очканул. А так...

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

Зачем использовать язык с произвольным доступом к памяти и потенциальными проблемами, с этим связанными, если можно этого не делать? Серьезно, вот хоть один аргумент, влияющий на данный конкретный use-case.

Честно?

Потому что существуют задачи, где приходится писать например свой менеджер памяти. Или использовать какой-то готовый. Иначе memory fragmentation в демоне, который относится к business critical или mission critical и его безнаказанно не перезагрузишь чтобы очистить ресурсы. Так что, выкусываем из общей памяти какой-то объем и дальше в его пределах выделяем-освобождаем области памяти, не залезая в остальную память.

С другой стороны, сообщество уже придумало инструменты для контроля как динамические, так и статические. Первое это valgrind/mtrace (#nclude <mcheck.h>, выставится хук на malloc()/calloc() и можно будет посмотреть где насрали). Второе это тот же splint. У меня основной редактор это vim, там стоит syntastic и настроен на работу со splint. Как только открываю исходник или записываю, так splint мне показывает в деталях где я дятел. И по работе с памятью тоже. Чего сложного-то? Авторы libcurl для себя не открыли splint? Там документация от 2003г. С тех пор,знаете ли, ни чего нового ни в срыве кучи ни в срыве стека не открыли. =))) Всё одинаково. И вот уже который год. CERT тоже свои рекомендации уже давным-давно выпустил. Нет, всё ходим фигнёй маемся. =)))

Да господи иисусе. Мы тут не говорим про ситуацию, когда чувак сидит с кастомными драйверами для ethernet, работающими в userspace, с hugetlb, собственным memory management и nvmeof в четыре pcie слота. У него json через php.

И как это зависит от языка?

Нет, ну серьёзно? Ну пока у него простая задача, да. А, не дай Бог, произойдёт её усложнение? Ну, например, он увеличит число опрашиваемых устройств? А они по сети работают, в разных сегментах, где разная латентность. Протокол двунаправленный, т.е., данные и с устройства и на устройство. И что делать? Вот мы и подбираемся к ситуации, когда он задумается о своём менеджере памяти.

Почему язык должен кого-либо в чём-то ограничивать? Проблемы с памятью, на мой взгляд, это как дизентирия. Болезнь грязных рук. Сделал malloc()/calloc(), ну так будьте любезны и free() сделать. Выделяете область памяти? Ну так проверьте возвращаемое значение и границы области... Это аксиоматично как сходили в туалет — помойте руки после посещения.=)

Это аксиоматично как сходили в туалет — помойте руки после посещения.=)

до посещения тоже надо

Нет, ну серьёзно? Ну пока у него простая задача, да. А, не дай Бог, произойдёт её усложнение? Ну, например, он увеличит число опрашиваемых устройств? А они по сети работают, в разных сегментах, где разная латентность. Протокол двунаправленный, т.е., данные и с устройства и на устройство. И что делать? Вот мы и подбираемся к ситуации, когда он задумается о своём менеджере памяти.

Крайне, КРАЙНЕ маловероятно. Разве что он данные через infiniband гонять начнет. Но чото я сомневаюсь.

Почему язык должен кого-либо в чём-то ограничивать? Проблемы с памятью, на мой взгляд, это как дизентирия. Болезнь грязных рук. Сделал malloc()/calloc(), ну так будьте любезны и free() сделать. Выделяете область памяти? Ну так проверьте возвращаемое значение и границы области... Это аксиоматично как сходили в туалет — помойте руки после посещения.=)

Зачем плодить attack surface ради мифической возможности заюзать собственный алокатор? Ну не файловую систему он пишет.

Если честно, то я не готов спорить.

И, более того, даже не хочу. =) Просто потому, что давно уже в своём коде научился не косячить. Тут вопрос в квалификации программиста, да. Но для меня, например, С гарантирует что код будет более-менее одинаково работать с минимумом оверхеда на практически любом железе. И на той же Raspberry Pi 2/3 и на дескопе и на сервере. Я не готов спорить просто потому, что я готов к решению задачи практически не задавая вопросов насчёт железа. Особо весело бывает на Orange Pi Zero W, но там мозгов всего 512М, так что с серверами там можно, конечно, но особо не разбежишься. Или на каком-нибудь роутере с 32М мозгов. Тоже бывает, хотя, mosquitto в той же OpenWRT есть и мой код даже работает. Даже там. Хотя, это и просто звиздец, конечно. Не для того оно. Но мне в принципе без разницы. Хочет заказчик, так почему и нет? =))) Он же бабки тратит, а не я.

Мне сидеть и думать над тем, на каком же языке мне вот это вот написать, просто зачастую и некогда. Просто пишем. Просто работает. Косяков, вроде, не наблюдается... А насколько это идеологически верно... Да похрен как-то. Если уж честно, то от стандартной библиотеки рантайма ещё ни кто не убегал. Вот я её и испоьзую без лишних уровней абстракции, привносимых другими языками. Так оно как-то проще получается. =) На мой взгляд.

По хорошему если, то да.

Надо.

Redis, Memcached? Всё ж придумали до нас

Redis, Memcached? Всё ж придумали до нас

А смысл ему данные туда-сюда гонять? К тому же, еще непонятно, что быстрее — получить данные из memcached, или из page cache.

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

Ну демон, держащий в голове префиксное дерево, пишется примерно за час. Но тут сама задача велосипедная :)

вот это, да :)

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

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

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

вообще, спасибо за комменты по делу. на ЛОРе это редкость.

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

Как этот ответ соотносится с вопросом?

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

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

Сырое, глючное поделие — go. Но баги, порча памяти и чтения за границей массива (потенциальный SIGSEGV) почему-то в curl. Ты не видишь тут противоречия?

почему-то в curl

А почему именно curl? Это про любую сишную либу можно сказать. Взять тот же libxml2. Там changelog просто сказка. double free на double free.

А почему именно curl?

Ну мы тут curl обсуждаем, потому что это чуть ли не единственная живая сишная либа для HTTP. И у Iron_Bug бомбит от того, что баги в сишной либе, а считать бажным языком нужно Go.

Это про любую сишную либу можно сказать. Взять тот же libxml2. Там changelog просто сказка. double free на double free.

Парни из OpenBSD творят чудеса в своих походах по минному полю. В релизных версиях не то чтобы много такого рода проблем. Есть, конечно, но не так много.

а считать бажным языком нужно Go.

Сишник - это диагноз.

Парни из OpenBSD творят чудеса в своих походах по минному полю.

Боюсь даже представить, насколько сильно это бьёт по скорости разработки.

Сишник - это диагноз.

Ну, я до сих пор пишу всякие сложные штуки, требующие какой-никакой скорости, на C. Я все хочу слезть на Rust, но их долгая война с асинхронкой меня немного пугает. Хотя вот tokio наконец-то избавился от шареного между тредами event loop'а. Я все надеюсь, что сейчас придет async/await, и жизнь станет мягкой и шелковистой.

Боюсь даже представить, насколько сильно это бьёт по скорости разработки.

Да не то чтобы сильно, на самом деле. Сильнее бьет то, что их мало.

потому что в C если я найду ошибку в библиотеке - я её исправлю. а если я использую библиотеку и в ней ошибка, то я её обязательно найду, так как тестирую свой софт. а в го хомячки просто страдают и ничего сделать не могут с багами. я это сама видела. и тормоза го тоже видела. так что не надо тут заливать. го - бажное тормозное УГ. оно недавно появилось и исчезнет. таких язычков навалом было. и все они канули в Лету. а на C пишут уже более 30 лет и всё работает.

а на C пишут уже более 30 лет и всё работает.

вообще-то намного больше

потому что в C если я найду ошибку в библиотеке - я её исправлю. а если я использую библиотеку и в ней ошибка, то я её обязательно найду, так как тестирую свой софт.

А тестировать софт на Go тебе мешает?..

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

Они их репортят, а разработчики фиксят. Или юзеры сами фиксят, и постят PR на Github. Все как всегда.

я это сама видела.

Я видел, как страдали и ничего не могли сделать с багами программисты на C. Все, закапываем? Я ожидаю пассажа в духе «ПРОГРАММИСТЫ ПЛОХИЕ БЫЛИ». Да, были. Так и программисты на Go у тебя тоже, скорее всего, были такие же. Дело в программистах, а не в языке. Править баги можно в софте на любом языке, инфа сотка.

и тормоза го тоже видела. так что не надо тут заливать. го - бажное тормозное УГ.

Важна область применения. Если делать сетевую хреновину, которая должна выжрать 400G через InfiniBand, обработать данные и послать их через NTB на другие серваки не поперхнувшись — да, использовать Go несколько наивно. Если тебе нужно REST API сделать — почему нет?

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

Языку десять лет. На нем написано дохрена полезного софта.

таких язычков навалом было. и все они канули в Лету. а на C пишут уже более 30 лет и всё работает.

Много на чем пишут. На Java пишут 23 года. Дальше-то что? Вот честно — лучше Go, чем Java.

Ну так в Си асинхронности нет в принципе. Так что хз.

Ну так в Си асинхронности нет в принципе. Так что хз.

В нем есть чудесный libev, в котором есть все, что мне когда-либо нужно было: таймеры, сигналы, поллинг fd и ивент луп без блокировок. С минимальными усилиями (ладно, у меня просто был чудеснейший QA, который самоотверженно все тестировал) я писал штуковины, которые мало ели, быстро работали, нравились админам в обслуживании и не требовали много сил для отладки. Да, автор наркоман и держит исходники с CVS. Да, callback hell. Но багов я с ним не ловил.

на Си есть всё, а чего нету, есть в ассемблере

а чего не libevent или libuv

а чего не libevent или libuv

Потому что libev простой, тупой и деревянный. libevent имеет в запасе HTTP, DNS и прочие штуки, которые мне были не нужны. libuv кроссплатформенный, что тоже было не нужно.

Если тебе нужно REST API сделать — почему нет?

Страшный же. И дженериков нет. actix-web + diesel всяко лучше и надёжнее.

Страшный же. И дженериков нет. actix-web + diesel всяко лучше и надёжнее.

Надежнее — хз. Я пока не убежден, потому что сам не видел. Код на Go видел. Да, без generic'ов плохо, но ребятки на работе почти все углы обошли через интерфейсы.

Ну и да — ничего страшнее реализации TAILQ (sys/queue.h) я в жизни не видел. Ну, не из быдлокода, а из нормально работающих реализаций. Так что если сравнивать вот этот вот и Go — выбор довольно очевидный.

ну, более и есть более. даже я на нём больше 30 лет пишу, если считать от момента, когда я начала его изучать, ещё в школе :) тогда он уже более-менее устаканился и был практически такой же, как сейчас. тогда был стандарт C89. то есть, он уже стандартизировался.

Хотя нет, видел — uthash.

В котором есть вот такие вот прекрасные комменты в коммитах:

This code is from before my time and I don't exactly understand it, but the intended usage is apparently...

Это который hash table на макросах?

Это который hash table на макросах?

Ага. Он хороший, быстрый, но код, как и в любой header-only либе, выглядит, как полусгнивший дрочащий бомж.

Хммм...

Это вы из-под оффтопика пишете? Да и то там, насколько я помню, процентов 80-90 системообразующих вещей, это С. В онтопике, наверное, и того больше. Ядро, да и базовый утиль.

Вы даже на сервере... Впрочем, молчу-молчу-молчу... =)))

Вы бы аккуратнее как-то с диагнозами-то? =)))

Благодарствую на добром слове. =)

Я просто верун христанутый, с ПГМ. Из этого и исхожу. Можешь помочь? Помоги. Не можешь, так просто посиди, молча послушай, авось и за умного сойдёшь. Вот и предпочитаю разговаривать... редко. Не более того. =)

я не запоминаю юзеров и не имею каких-то целей кому-то понравиться или за кого-то «сойти». я комментирую конкретные посты. это не распространяется на всё остальное. и это форум про Linux, да. а не про сказки овцеводов Синая.

Я не по Вас лично.

Консенсус. =)

Ну вон, твоя любовь 20 лет на сях говорят пишет, опыт, наверное, имеет. Тут собрались пацаны, написали но и на полном серьезе не могут понять почему все тут же си не побросали.

Я не так давно живу, но постоянно наблюдаю как новомодные языки появляются как чёрт из табакерки, а через эн лет никто уже про них и не помнит.

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

Она, конечно, больная, но насчёт того что языку бы лет 10 настояться, а там посмотрим, дело сказала

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

Эм... где я такое говорил? Ты либо меня жирно троллируешь, либо читать не умеешь. Я абсолютно согласен с тем, что полностью заменить C сейчас очень, очень сложно. Но тем не менее, я достаточно хорошо его знаю, чтобы сказать — да, язык имеет жирный недостаток, который можно устранить и получить более хороший язык. Почему этого не сделать? Более того, определенные вещи, не требующие супер-пупер производительности, можно написать на других, более безопасных языках.

Да не говорил, конечно, я гиперболизирую.

Да, недостатки есть, никто ж не спорит.

Ты просил назвать хоть одну причину, почему не написать на го, ведь там нет этого недостатка:

Опыт. На си я умею, на го пока нет.

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

Литература.

Старшие товарищи, у которых можно спросить.

Инструментарий. Анализаторы кода, например, отладчики

Перспективы учить го. Ну как завтра его забросят авторы? Про си такого страха нет.

Наличие готовых решений и масса открытого кода.

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

C++ конечно так и сочится из твоего текста, но он слишком жирный и наверно никогда не сможет конкурировать. Се ля ви, что называется.

Чини детектор.

Ну тебя никто не заставляет писать на Go.