Comments 84
хм. в чем логика при известном уставном капитале прятать абсолютную величину вклада, но оставлять процентную? или я неправильно понял?
Может потому, что доля не обязательна равна вкладу в уставной капитал?
>при известном уставном капитале прятать абсолютную величину вклада
смысл тут спрашивать? у ФНС спросил бы. Там ещё любят десятичные дроби
впрочeм у вебсервера, всё нормально
"sharePart" : 16 , "sharePartRUR" : 80000, "name" : "ключкин антон сергеевич"
когда форкается софт не ради фич или стабильности а из-за политических причин значит в мире всё ОЧЕНЬ плохо
Нет, с миром то всё в порядке. Все друг друга воруют, грабят, душат, режут и вешают. В общем идёт обычная, цивилизованная жизнь. Макдональдсов в последнее время не видно, что не может не радовать. Ничего не меняется.
с учётом того что продукто опенсоурсный - то окликнутся мог в принципе любой.
я имел ввиду что ответить в принципе мог кто угодно. в данном случае ответили разработчики. если помощь оказал бы абстрактный Вася Пупкин - то были бы вопросы к нему? а если бы разобрались бы авторы вопроса - тогда к кому были бы вопросы? или может при возникновении вопроса такого надо было вообще удалить софт и прекратить разработку - раз оно вообще позволяет такое делать?
И тут к вам приходит какой-то тип и спрашивает, мол, брат, помоги, у меня есть задание от государства мучать и расчленять живыхдетейкотят, пытаюсь делать это твоим ножом, но чето не получается, подскажи что я делаю не так?
гхм, всё-таки возможность для спецслужб читать трафик конкретного сайта — это несколько другая ситуация, чем описанная вами.
и да, если вы прочитаете вопрос, то у людей на апаче уже всё работало; ну не ответил бы максим, так бы остались они на апаче — мир стал бы от этого лучше?
Ну как помог, там в ответах только совершенно очевидные вещи из разряда "попробуйте почитать логи".
Прекрасная подмена:
один разработчик -> разработчики, они
однажды ответил на вопросы пользователя из списка рассылки сообщества -> охотно помогали.
Процитирую начало сообщения, на которое вы ссылаетесь:
> Мы состоим в реестре организаторов распространения информации и
поэтому обязаны предоставлять в надзорный орган ключи tls сессий.
Видимо если бы бывший коллега не подсказал, то озвученная обязанность пропала или автор не продолжил бы использовать Apache, с которым у него уже все работало без проблем. К разработчикам Apache тоже вопросы?
На ваш пример у меня есть свой пример. Сюжет тот же, но только помочь надо остановить насильника или террориста. К чему эти фантазии?
Очевидно, что преступники и террористы пользуются шифрованными каналами связи для подготовки своих преступлений. В то же время бывают и обратные ситуации, когда злоупотребляют полномочиями не для тех целей, которым по идее должны служить. Мир не состоит из черного и белого.
Мы то все видим, просто вы не все говорите что в статье написано. Модуль для веб-сервера для перехвата tls траффика написан нидерландскими спецслужбами. В статье даже все адреса приведены.
Интересно, а сколько всего форков Nginx существует?
основной, Pro, китайский форк, а и теперь angie?
Военком на мотив Земфиры: "Больше всего нужны // Мне твои камбэки".
Часть команды разработчиков Nginx вернулась в Россию
Это выглядит как пропаганда самоубийств.
О, софт созданный по политическим причинам с целью заработка в мордоре - всегда мечтал о таком (нет).
Ничему их жизнь не учит, посадят ведь в конце концов, или на фронт сошлют.
Сколько % "учредителей и участников" подпадают под моби....ию? Их поэтому так много, чтобы хоть кто-то остался?
Да ну ладно, вернулись в Россию? Что за желтизна. Очевидно, это те сотрудники, которые не релоцировались в США после начала воблы.
Больше интересно почему инвестиции в проект в долларах идут. Проект же импортозамещения, причем тут доллары?
Инвестиции команды в проект на первом этапе уже составили $1 млн.
А почему не рассматривается вариант, что просто в России жить нравится больше, чем в других странах? Людям может просто нравится жить в родной стране, среди родных людей, разговаривающих на родном языке. Я думаю это точно важнее денег.
Потому что в это сложно поверить. Не очень понятно как "родное" может оказаться важнее, чем возможность быть убитым или посаженным в тюрьму?
Было бы не плохо, если бы разработчики переписали configure и auto/ скрипты на какой-нибуль вменяемый лад (autotools или хотябы meson), а то cross-сборка Nginx без патчей представляется весьма нетривиальной задачей.
cross-сборка Nginx без патчей представляется весьма нетривиальной задачей.
гхм…
https://github.com/buildroot/buildroot/blob/master/package/nginx/nginx.mk
мейкфайл, конечно, длинный, но исключительно из-за того, что в него запихали кучу вариантов сборки. если урезать до одного варианта, то на один экран поместится
я не про то как собирать Nginx, а про то, как Nginx конфигурирует код под выбранную пользователем архитектуру.
ну вообще-то buildroot — это инфраструктура для кросскомпиляции.
делаете make menuconfig, выбираете архитектуру, что нужно собрать, потом делаете make — вуаля, скачается и соберётся gcc, libc,… под выбранную архитектуру. и nginx тоже, если соответствующую галочку поставите.
как говорится, всё украдено до нас
Спасибо за напоминание. Действительно, с кросс-компиляцией беда. Занес ваше пожелание в список потенциальных улучшений.
Когда начнете работу, расскажите на каком средстве конфигурирования остановились.
Лично я предложил бы autoconf/automake, по тому, что autotool поддерживает практически все доступные операционные системы. Однако не могу навязывать решения. Meson+ninja тоже подойдет, но с ним пользователю приходится создавать т. н. toolchain файлы с параметрами (для более строгой поддержки целевой архитектуры), а это усложняет системы автоматической сборки.
Плохое рекомендуете.
Тут думать надо.
Думать надо всегда.
Чтоже плохого в autotools?
Как я понял autotools для конструирования configure.ac дает некие хелперы типа AC_SEARCH_LIBS. Но большую часть кода надо будет написать вручную. В результате оно работает у разработчика, но часто просто море мелких багов. Например из того что встречал - конфигур корректно находит либу через pkgconfig, но потом начинает тестировать фичи и делает просто -lлиба $LIBS, корректно подставить LIBS из pkgconfig забывают, да и самостоятельно писать -lлиба тут некорректно, надо было pkg-config либа --libs.
В результате проверки провалились, но либа подцепилась, имеем молча недоработающее приложение. Meson же дает возможность не писать больше ручного кода -> меньше ошибок в разных конфигурациях.
С каких пор autotools стали вменяемыми?
И ещё вопрос. Я не оч. понимаю нафига nginx'у кросскомпиляция? Хотелось бы случай из практики, т.к. у меня такого как-то не случалось, что это прям надо, и придумать зачем это надо я не могу. nginx это не toolchain - зачем ему это? Либо собирать прям на железке, где он нужен с подключенным внешним usb-диском для swap, либо сделать виртуалку qemu с нужной архитектурой и собирать там с любым кол-вом оперативы и дискового пространства. Так зачем кросскомпиляция?
Ожидал на сайте увидеть тарифные планы, мол, мы можем поддерживать корпоратов постетухода основной компании по похожим принципам. Но продукт бесплатный и в чем смысл тогда компании? Инвестиции на будущее? Но сейчас российские компании остались без плюса и им нужна альтернатива.
Могу ошибаться, но вроде как geoip модуль был раньше в plus редакции, а сейчас он на сайте представлен у этих ребят.
Для начала надо обеспечить нормальное конфигурирование исходников для кросс-сборки. Затем подумать о GeoIP, ведь старая либа не актуальна, а новый maxmind закрыл от россии бесплатную версию взвентив цены на платную, так что с GeoIP надо решать. На мой взгляд, надо делать собственную базу и наполнять ее с помощью бесплатных online сервисов. Иначе запад так и будет все хранить у себя, а с "развивающихся" стран продолжать собирать подати.
Nginx проект классный, но его надо доводить до ума именно в плане содействия тем, кто готовит пакеты для различных дистрибутивов Linux, Unix, BSD,... да и на minix не мешало бы, ведь Nginx достаточно компактный и модульный.
VBart
мне иногда не хватает апачевского mod_status.so: видеть не какие запросы были, а какие запросы есть прямо сейчас.
нет планов сделать что-то подобное?
Да, было бы здорово такое реализовать. Но в nginx это достаточно нетривиальная задача. Можно получить информацию о запросах, которые обрабатываются в том же процессе, куда поступил запрос к статистике, но для извлечения информации из других рабочих процессов потребуется некий механизм ipc, который на данный момент в nginx просто отсутствует. Думаю рано или поздно мы это реализуем.
вот вроде что-то в этом направлении https://github.com/Taymindis/ngx_lfqueue
Нет, на первый взгляд это совсем не то. В nginx есть разделяемая память и структуры данных, которые могут в ней жить. Данный модуль похоже просто реализует интерфейс к такой структуре типа очереди в разделяемой памяти.
Рабочие процессы могут добавлять элементы в эту память под мьютексом или lock-free, но им не нужно знать ничего друг о друге. Манипуляции с памятью целиком и польностью осуществляет тот процесс, в который пришел соответствующий запрос и ему не важно, что там происходит в других процессах, сколько их, существуют ли они вообще, и т.д., до тех пор, пока изменения происходят атомарно (за счет мьютекса или lock-free алгоритмом).
У нас же задача значительно сложнее:
1. Каждый рабочий процесс, в который может потенциально прийти запрос статуса, должен знать о существовании других процессов.
2. Поскольку сами процессы их число - величина не постоянная, то в момент, когда какой-то из процессов завершается или стартует новый, другие рабочие процессы должны узнавать об этом и получать каналы связи с новыми процессами.
3. Через эти каналы связи процесс, в который придет запрос статуса должен будет запросить из других процессов информацию, разбудив их и дождавшись, когда информация поступит из каждого процесса.
4. Все это сопровождается обработкой всевозможных race conditions, например, когда мы направили запрос в процесс, который как раз решил завершиться в этот момент, но он ещё не получил запроса, а мы ещё не получили информации о том, что он завершается.
5. Сама разделяемая память разумеется может служить таким каналом связи, но будет необходим ещё механизм, который позволит будить процессы, уведомлять их о новой информации или запросе из другого процесса.
я сейчас страшную вещь скажу, но почему бы не решить проблему получения списка текущих коннектов, а не разработки полноценной системы ipc?
наивная реализация, сходу приходящая в голову:
- головной процесс держит открытым сокет, адрес которого знают все воркеры;
- по
angie -s statusворкерам шлётся USR2; - получив USR2, воркеры пишут в сокет мастеру необходимую информацию;
- головной процесс выводит полученную информацию (и ругается, если кто-то из воркеров не ответил за разумное время).
(я не говорю, что нужно делать именно так, только иллюстрирую, что проблема может быть решена малой кровью)
Головной процесс работает от root и не принимает клиентских соединений, как по соображениям безопасности, так и стабильности (его падение будет фатальным).
То, что вы описали - больше похоже на некий дамп, который может сделать только админ локально. Но это в целом то и сейчас можно сделать, написав скрипт с использованием gdb, который подключится к каждому процессу и извлечет всю нужную информацию из его структур. А сравнивать длину костылей нет большого смысла.
А не думаете с многопроцессной системы на мультитредную перейти? Какие сдерживающие факторы?
Собственно в Unit-е мы это сделали.
Сдерживающие факторы такие, что это другой продукт получается, который не будет совместим со всеми сторонними модулями, а также потребует переписывания заметного количества кода существующих модулей. Дело в том, что весь текущий код nginx и сторонний код написан в парадигме отсутствия необходимости обеспечения thread-safety.
Процессы лучше, это нормальный unix-подход: например, как BSD inetd: поймал клиента, дал ему обслуживающий сервис и отдыхай.
Ничего себе, внезапная новость! Если внедрят в астру, то она точно далеко пойдет
Часть команды разработчиков Nginx вернулась в Россию, запустила проект Angie и будет поддержкой клиентов Nginx в стране