| 1.2, Аноним (-), 23:24, 12/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
> разные версии языков
> Perl
Спасибо ребят за perl, будем изучать. Кажется я нашел где находится лучшее решение по организации test&&deploy поверх разных версии perl на базе NGINX Unit. Надо обкатать.
| | |
| |
| |
| 3.23, Аноним (-), 19:23, 13/04/2018 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> Что таки остались люди использующие перл в проде?
То чувство когда ты вдруг осознаешь что реальный мир вокруг отличается от твоего представления?
| | |
| |
| 4.29, пох (?), 09:44, 17/04/2018 [^] [^^] [^^^] [ответить]
| –4 +/– |
>> Что таки остались люди использующие перл в проде?
> То чувство когда ты вдруг осознаешь что реальный мир вокруг отличается от
> твоего представления?
да знаем мы что в мире все еще воруют у археологов мумии программистов на коболе, знаем.
| | |
|
| 3.27, антончик (?), 19:35, 16/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не поверишь, но в мире есть люди, которые не только что закончили школу и сразу побежали на первую галеру писать на модном-молодёжном языке профессионального программирования жопаскрипт.
| | |
| |
| 4.28, пох (?), 09:43, 17/04/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
а сделали это все двадцать лет назад, и борода уже седая, а все та же цепь, почти не заржавела, и то же весло - почти и не стерлось?
(кстати, имейте в виду, модным-современным пластиковым грести легче, чем этим вашим тесанным из цельной сосны, хотя мозоли первое время и будут мешать, а новые образуются не сразу и в других местах)
нет, серьезно - кому-то все еще *нравится* программировать вебню на перле? И не потому что ниасиляторы, ибо возраст уже не позволяет ничему научиться, а "есть законченные проекты на руби/питоне/жабе..ЭЭ/php на худой конец, для данной задачи перл подходит лучше" ?
| | |
| |
| 5.38, Gogi (??), 12:51, 09/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
А чем вообще "вебня на перле" отличается от той же на "пестоне"?? У перла есть аналог ASP, позволяющий чётко выдавать контент. Сам язык - удобный, много полезных конструкций, есть ООП. Не писать на перле - это просто придумывать себе оправдания.
| | |
|
|
|
|
| 1.5, Аноним (-), 03:39, 13/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
То есть чтобы определённую конфигурацию загрузить при старте/рестарте юнита, мне нужно завести скриптик вызывающий curl, чтобы он накидал юниту что и как делать.
Странно что это не предусмотрено изначально...
| | |
| |
| 2.6, кверти (ok), 04:06, 13/04/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Странно, что ты вообще тогда нужен, если за тебя все можно сделать
| | |
| 2.19, Anonimus (??), 18:21, 13/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> То есть чтобы определённую конфигурацию загрузить при старте/рестарте юнита, мне нужно
> завести скриптик вызывающий curl, чтобы он накидал юниту что и как
> делать.
> Странно что это не предусмотрено изначально...
Смысл юнита в том что б менять конфиг на лету без рестарта.
| | |
| |
| 3.30, пох (?), 17:48, 17/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Смысл юнита в том что б менять конфиг на лету без рестарта.
перечитать текстовый файл (и "без рестарта") модные-современные программисты ниасилили?
(и да, если мне понадобится этот файл передавать из "уеб-приложения" [с кучей грабель при таймауте/ошибке/проблемах в самом приложении по пути] - уж поверьте, я как-нибудь сумею написать сверхсложный интерфейс, который в одну дырку принимает его из того же nginx'а, а из другой записывает в предназначенное для конфигов место. И даже без unit для этой мегахайлоадной задачи обойдусь.)
Впрочем, после вебинара про mod_security у меня странные мысли про тех людей, которые работают в nginx co.
| | |
|
|
| 1.8, evkogan (?), 08:48, 13/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А разграничение прав в API насколько гибко-диференцированное, можно на отдельный сайт права раздавать, чтобы получить аналог .htaccess?
| | |
| |
| 2.9, Аноним (-), 11:41, 13/04/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
.access не нужны, координацию запросов должно выполнять приложение на любом языке программирования
В последние годы только используют index.php+static и подобные, а все остальное скрыто на уровне выше.
| | |
| |
| 3.10, Василий Топоров (?), 11:48, 13/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Очень даже нужны. Гораздо проще прописать один раз правило для редиректа (301-го, например) в .htaccess, чем дергать лишний раз тяжелое приложение для этого.
| | |
| |
| 4.11, Аноним (-), 12:08, 13/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Это ведь не значит что нельзя, просто не рекомендуемый способ для application server.
| | |
| 4.21, Anonimus (??), 18:26, 13/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Очень даже нужны. Гораздо проще прописать один раз правило для редиректа (301-го,
> например) в .htaccess, чем дергать лишний раз тяжелое приложение для этого.
... и тяжелое приложение для каждого запроса будет читать твой файлик и сканить рекурсивно папки замедляя работу сайта... Это же лучше чем просто перечитать конфиг командой reload?
| | |
| |
| 5.33, пох (?), 18:09, 17/04/2018 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> ... и тяжелое приложение для каждого запроса будет читать твой файлик и
а по другому ты уже не умеешь? Вон из профессии!
> сканить рекурсивно папки замедляя работу сайта... Это же лучше чем просто
> перечитать конфиг командой reload?
это лучше тем, что у тебя нет доступа к тому конфигу. Ибо им ты поломаешь не только свою косорукую поделку, но и соседние. Поэтому пиши заявку в жиру, мы лет через пять до нее доберемся и "перечитаем конфиг", предварительно проверив на тестовой ферме, специально под твое изменение собранной (это еще пару лет займет).
а мог бы ты писать в .htaccess - давно бы домой улетел.
(впрочем я знаю, ты вместо этого будешь рерайты и редиректы вместе с базовым контролем доступа пихать не в "тяжелое" приложение nginx, а в "легкую" хрень на пихоне/жабе/что там сегодня модно, всего пятьсот мегабайт rss с рестартом интерпретатора на каждый запрос)
"папки" говорят сами за себя, ага. (и нет, чтение даже десятка .htaccess - ни разу не ресурсоемкая операция. Если сделать как надо, а не как ты cумеешь. В том числе потому, что файловые системы по сей день разрабатывают те кто умеют, а не разработчики на модных языках.)
блин, дайте какой-нибудь другой глобус, этот засран окончательно :-(
| | |
|
| |
| 5.34, пох (?), 18:10, 17/04/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Если вам нужен htaccess, вам не нужен nginx unit.
nginx unit не нужен, мы уже поняли.
| | |
|
|
| 3.12, evkogan (?), 14:34, 13/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> В последние годы только используют index.php+static и подобные, а все остальное скрыто
> на уровне выше.
А может кто-то ответить по делу, нужны/не нужны это другой вопрос.
Я спрашивал насколько хорошо разграничиваются права на API, можно сделать аналог .htaccess или нет.
| | |
| |
| 4.32, пох (?), 17:59, 17/04/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А может кто-то ответить по делу, нужны/не нужны это другой вопрос.
> Я спрашивал насколько хорошо разграничиваются права на API, можно сделать аналог .htaccess
> или нет.
нет. Сысоев никогда не работал в организациях, где админы веб-фронтендов и приложений - разные недружественные команды, тем более - никогда не занимался хостингом untrusted сайтов.
Поэтому в свое время эту вещь делать не стал, объявив что ему она не нужна и портит всю музыку.
нынешние неспособны. Все на что их хватило, это вот выкатить на-гора универсальный fpm.
Так что и не ждите. Пишите скрипты/мэйкфайлы/юзерфрендли интерфейсы/чорта лысого для решения этой проблемы. Это всерьез и надолго, скорее всего - навсегда.
| | |
|
|
| 2.18, Anonimus (??), 18:20, 13/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
Нельзя и никогда не будет можно. Приложение для другого предназначалось. Отдельные права на отдельный сайт вы можете раздавать и в nginx, а прямой аналог .htaccess никогда не появится в nginx и ранее кучу раз обсуждалось почему он не нужен.
Данное приложение, если очень грубо и брать во внимание только работу с php, по своему принципу работы аналогично работе nginx + php-fpm + upstreams, но с возможностью менять настройки php-fpm без рестарта php. Эта штука больше заточена под hi-load. Для своего блога есть смысл продолжать использовать классическую связку nginx + php-fpm.
| | |
| |
| 3.31, пох (?), 17:55, 17/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> аналог .htaccess никогда не появится в nginx и ранее кучу раз
> обсуждалось почему он не нужен.
патамушта ниасиляторы, да. К этому все и сводилось. (и да, htaccess не так прост как кажется на первый взгляд, нормально реализовать его в существующей архитектуре нынешние манки-кодеры не смогут)
> upstreams, но с возможностью менять настройки php-fpm без рестарта php. Эта
> штука больше заточена под hi-load. Для своего блога есть смысл продолжать
настоящему highload абсолютно фиолетово на рестарт единичного php-fpm. (который может и сам йапнутся от миллиона причин, или сервер под ним)
Это ваши блохи разбегаются, потому что он у вас вообще один-единственный.
> использовать классическую связку nginx + php-fpm.
то есть ненужнейшее ненужно, я вас понял.
к php-fpm есть определенные претензии. Но вы явно не в курсе.
| | |
| |
| 4.37, нет (??), 23:46, 18/09/2018 [^] [^^] [^^^] [ответить]
| +/– |
Все у тебя есть претензии ко всему, всех успел обосрать не приведя не одного адекватного аргумента. Тебе никто не хочет даже доказывать то, что есть в открытом доступе и 100500 раз обсуждалось.
Мне кажется что ты просто страдаешь неофобией, или просто идиот :)
| | |
|
|
|
| 1.26, rvs2016 (ok), 19:14, 16/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Чё-то я не понял - в чём радость?
Описали то, что можно делать в Apache.
Обычная система CGI что ли? А назвали-то! Сервер приложений...!
| | |
|
