Выкинул nginx, перешел на Angie

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

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

недавно тестировал (ab) apache и nginx статику и fpm-php.

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

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

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

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

а чего его «тянуть»? он всегда есть на машине, если ты собираешь кернел и прочие сорцы. perl -pe - наше ффсё. это вообще базовый инструмент работы в консоли. поиск, замена данных в файлах и прочее - это всё он самый. он работает намного шустрее sed'а (особенно это заметно на больших файлах или на больших количествах файлов) и у него гораздо более мощные регекспы. он реализует весь спектр их возможностей. это великолепный инструмент.

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

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

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

ACME - это стандарт. последнее изменение стандарта было в 2018 году и с тех пор он не менялся.

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

LE не могут ничего поменять в стандарте

В стандарте нет, но в реализации могут.

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

Предпочитаю придерживаться принципа KISS, а не изобретать/писать велосипеды по любому поводу.

да был период он (apache) только при скачивании статики больших файлов (образов iso) мог дотянутся до nginx, а тут я в растерености, что можно испортить.

Предпочитаю придерживаться принципа KISS, а не изобретать/писать велосипеды по любому поводу.

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

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

есть огромный зоопарк портянок на bash

У меня тоже.

питон всё же приятнее баша и даже безопаснее, но тянуть его и его окруждение на сервер безумие

У меня оно в отдельных vm обитает.

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

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

он работает намного шустрее sed'а (особенно это заметно на больших файлах или на больших количествах файлов)

У меня как раз обратная статистика. Но не исключаю, что в текущих реалиях оно и так, давно не держал я перл в руках на тему регэкспа.

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

Не обязательно прям любой, но в целом да.

как умение админить серверы и сети. базовые вещи.

А вот это как раз не обязательно. А сети так вообще не в кассу.

вот только принцип KISS распространяется на софт, а не на мозг.

Последняя S намекает на мозг.

и да, если бы ты действительно придерживался принципа KISS, как я, например, то ты бы никогда не поставил на сервер такой отвратительный жир, как пистон.

Ну если говорить про прод, то certbotы у меня в анально огороженных песочницах крутились.

а тем временем у тебя на сервере пистон

И что с того что на сервере может быть пистон? Вы таки раскройте свою мысль пжлта.

который кроме того, что он жирен

Обьем занимаемый удавом на харде при объемах современных носителей ничтожен.

как фиг знает что, так ещё и дыра в безопасности.

Каким образом по вашему мнению наличие удава на сервере может повлиять на безопастность? Я без подколов, догадываюсь, что у вас есть какая-то своя мысль реализации, но вы её не озвучиваете.

у тебя поди ещё и ненужно-д там есть, а?

Это не угодно богу, так что везде где есть возможность обходиться без него оно отсутствовало и отсутствует.

у меня с перлом был опыт переписывания скриптов для всяких утилитарных нужд у ОПСОСа. там логи БС и они, мягко говоря, немаленькие. а по этим логам иногда надо делать разные выборки для манагеров, иногда даже для юзеров. и вот некоторые выборки для манагеров выполнялись сутки и более. через серию небольших оптимизаций, в том числе через perl, я сократила время работы с суток до 2 часов. ко мне пришли программисты из отдела по обработке данных и попросили меня объяснить на пальцах, какую «магию» я применила и почему оно стало работать так быстро :) я просто оптимизировала регекспы.

но я отдельно гоняла простые запросы sed'ом и perl'ом на больших файлах и perl был существенно быстрее. хотя иногда отжирал немало так памяти. ну и файлы там многотерабайтные.

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

Это не угодно богу, так что везде где есть возможность обходиться без него оно отсутствовало и отсутствует.

ну хоть это хорошо :) мне немного полегчало. а то я уже заподозрила нехорошее.

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

Каким образом по вашему мнению наличие удава на сервере может повлиять на безопастность? Я без подколов, догадываюсь, что у вас есть какая-то своя мысль реализации, но вы её не озвучиваете.

у меня нет «мысли о реализации» пистона. у меня есть мысль о его тотальном изничтожении. и я её постепенно реализую.

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

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

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

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

почему он небезопасен? потому что тащит из сети всякое и потом запускает это на сервере.

Понял вот почти ничего. Я понимаю, что удав это такая змея в природе и она действительно тащит и использует это в себе, но вот как Python может сам по себе что-то тащить и тем более запускать на сервере я не понимаю. Имхо ваше выражение аналогично «gcc тащит из сети всякое и потом запускает», надеюсь аналогия понятна.

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

Остапа Яну понесло, уже и жабаскприпт с удавом скрестили...

там сама архитектура неправильная в корне

Опять слова.

плюс неправильная реализация. плюс полный бардак и невозможность всё это валидировать.

и это туда же.

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

Вы просто макак в естественной среде не встречали, удав тут не более чем «природный зоопарк».

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

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

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

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

Ну это какой-то суровый ынтерпрайз не позволяющий использовать для задач какую либо другую субд кроме оракла. Я с таким сталкивался в далекие годы в газпроме, там было только два варианта: субд это оракл и локальные это access. ВСЁ! вашу налево, никакой самодеятельности, чего-то среднего не предусмотрено от слова совсем. И вот там где нечто среднее прям само проситься на использование, ты вынужден мучать оракл выгружая данные в локальные мать их access, а потом и сам это долбанный access иметь на нехилых обьемах. А всего-то проблем, пришел некий главнюк который это с печатью и подписью провозгласил «да будет так и никак иначе».

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

субд это оракл и локальные это access

Странно, зачем access если есть оракл?

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

Просто ещё не остановилось течение.

я не хотела бы видеть «макак в естественной среде».

А зря. Я где-то полдня или чуть больше провел в одном национальном зоопарке, достаточно интересно. Во всяком случае у меня остались самые позитивные воспоминания.

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

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

Без анализа бизнес-процнссов трудно что-то сказать, но выглядит как глюк какой-то.

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

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

Странно, зачем access если есть оракл?

На всех ораклов ненапасешься это раз. И не у всех есть место где развернуть оракл это два.

и как-то меня укусил яванский макак.
приматы во мне не вызывают никаких симпатий. они злобные, хитрые,

Ага :) Там в зоопарке всё плакатами для не умеющих читать (это разумно, на весь мир языков не напасешься) было обвешано в виде:
картинка один: «протянул макаке банан»
картинка два: «макака укусила за палец»
картинка три «доктор за которым стоит скорая».
Просто и доступно.

Зачем много? Достаточно одного.

Зачем много? Достаточно одного.

Одного на всю Россию? Вы вообще внимательно прочитали тот пост на который ответили? Рекомендую обратить внимание на название компании у которой это было.

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

Я участвовал в этом процессе. Это было в конце 1990 начале 2000. Оракл это же 2 в 1 и с большими объёмами хорош. В общем выбор понятный так как альтернативы были хуже. Возможно db2 бы зашёл, но не довелось.

Я сам Sybase пробовал - не то пальто.

Хотя теперь понимаю логику - выгрузка фрагментов бд в филиалы. Этакая распределённая БД.

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

Хотя теперь понимаю логику - выгрузка фрагментов бд в филиалы. Этакая распределённая БД.

Все ещё плохо понимаете. Это не выгрузка, это синхронизация данных в обе стороны.

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

Это детали уже.

Это! Нихрена не детали! Синхронизация данных в обе стороны != выгрузке из какой-то 1ц.

ну, помнится, распечатанная мелко на бумажках А4 и собранная из кусочков эта база занимала самую большую стену в нашем офисе, от пола до потолка, целиком. так что «на бумажке» было бы проблематично. это была бухгалтерия отдела капстроительства ЖД. а и них была просто туева хуча разнообразных данных, которые участвовали в бухгалтерском учёте.

Понятно, усложнили себе жизнь. Я что, спорю что-ли.

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

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

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

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

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

А вот это было, есть и будет есть злом! Работа с данными должна быть в первую очередь осознанной, а вот всякие автоматизации и порождают 1ц &co.

нормально там всё было. в те времена не было никакого сраного «ИИ» и всё это генерировалось софтом, который писали разработчики БД. а они лучше всех знали, как она работает. ты бы сам «на бумажке» больше накосячил, чем эта софтина.

Явно не поняли, ну и ладно.

нормально там всё было.

Только в ваших фантазиях.

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

«Разработчики БД» ничего не знают о вашей БД, генерить они могут только среднее по больнице.

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

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

Телепаты в отпуске

Телепатия не поможет, если базовых знаний нэма.