Насчет полифила: мне нужно лучше изучить этот вопрос, набрать больше примеров, возможно, залезть в исходники того же webkit. Нужно еще лучше протестить относительные размеры (пока на простом примере повторил только с transform, то с теми же margin/padding/width/height/etc не удается). Занимаюсь этим вопросом в фоне в связи с отсутствием достаточного времени. У меня ощущение, что встречал такой же баг, когда был указан, например, height: 5rem со странным дробным font-size (высчитанный специально в медиа-запросах), вчера пытался повторить, но не смог. Видимо, там были еще условия, либо транишны, либо те же трансформы на каком из блоков.
Пока что ощутимый баг для меня есть с transforms, все остальное я правлю с помощью препроцессоров, округляя и подгоняя размеры заранее (чтобы не было много знаков после запятой или периодических дробей, либо были, но при этом тестирую в разных браузерах). Кажется, браузеры сейчас очень хорошо округляют во многих ситуациях.
Игорь Б: в общем, начните дебажить все по порядку. Сначала сам тоннель до сервера, доступность клиентов в обе стороны. Тут вскроются проблемы с фаерволлом, если есть. Потом трейсить/смотреть таблицы роутинга/фаерволлы дальше до нужного вам узла. Если накидаете в комменты трейсов, описания узлов/сетей, что за тоннель (openvpn, pppoe, pptp и т.п.), то может кто-то вам и подскажет что.
Может быть, вы видите друг друга во все стороны на уровне ip/icmp, и проблемы в роутинге нет вообще, но какой-то фаерволл по пути обрезает нужный tcp-трафик (или что там у вас). Без знаний топологии можно только тыкать пальцем, вариантов такого поведения много.
Игорь Б: возможно, у вас там несколько сетей/интересный роутинг, поэтому получаете странное поведение. Или фаерволл на клиенте все режет. Но если взять именно VPN-тоннель в отрыве, то он всегда двусторонний.
Приведу пример, когда тоннель может выглядеть односторонним. Например, может быть такое, что вы устанавливаете тоннель до сервера, это одна сеть. Там дальше на сервере происходит, допустим, NAT в иную сеть. В итоге с тоннеля вы видите удаленный узел через NAT, но наоборот нет. Тоннель сам при этом все равно двусторонний, просто фишка роутинга. Таких вариантов может быть много. Изучите вашу топологию, посмотрите трейсы, посмотрите настройки VPN-клиента (точно вы к серверу обращаетесь или же у вас клиент-клиент обращение, видимость в котором зависит от настроек vpn-сервера).
Вадим Егоров: cgi/fastcgi не могут получить такую информацию от apache (они ведь работают через сокеты), прямой связи с веб-сервером нет. Поэтому в вашем случае либо не использовать shared-хостинг и иметь полноценный доступ к ОС, либо никак.
Мне ваша идея не очень нравится. Что мешает посмотреть список запущенных модулей, решить, что нужно и включить? Зачем смешивать веб-сервер и приложение? Ну будет инфа в отладке, но ее не так долго получить через ПА, либо, если это не shared, сразу из консоли.
Есть пакет https://github.com/monetizeio/sqlalchemy-orm-tree, оно предоставляет методы, выглядит неплохо. Если мигрировать с джанги на это, то покажется сложно даже на этапе настройки: там нужно описать таблицу, описать класс, замапить их (классический маппинг sqla). Доки относительно скудные (но если читались доки у sqla до этого, то нормально).
Этот пакет в бою не использовал, только "прицеливался" когда-то, выглядит нормально.
Что касается управления:
Нет админки (расширений для flask-admin не встречал), поэтому придется какой-нибудь jqtree вкручивать руками. Конечно, никакого удобного рендеринга в шаблонах.
Ни в коем случае не рекомендую это для обычных деревьев в интернет-магазинах и т.п.
p.s. А у django-mptt полет нормальный. Использовал еще mptt-admin, немного кастомизировал его (ajax-обновление некоторых свойств из попапа в самом дереве) - никаких проблем не вызвал. Единственное только, была проблема с django-cacheops: при перемещении узлов дерева в коде mppt-admin не вызывается save() по умолчанию, а поэтому и не поступает сигнал об инвалидации. Это если используется автоматическая инвалидация. Но это должно лечиться вызовом save() (там для этого как раз есть свойство).
p.p.s. А вот со сложными деревьями все обстоит сложнее. В случае если элементы дерева сильно неоднородные и нельзя для них использовать 1 таблицу (как минимум, адский оверхед и неудобно в админке), если же деревья пересекаются (django-dag) или нужны какие-то операции над узлами (допустим, определенные узлы и их потомков рендерить иначе), то, как минимум, все адско обрастает полями типа "рендерить как товар?", "рендерить как группу?" или "как группу, но чтобы товары были видны?" и т.п. А как максимум для неоднородных деревьев требуется сочетание с nosql, в итоге огромные правки в админку, в модели (менеджеры) и вообще в логику. У меня есть один проект, у которого клиенты хотят иметь неоднородное дерево и удобную админку, но пока что обходятся стандартным django-mptt, ибо само дерево в ужасном состоянии, а сеошник вписывает в title бренды, нарушая тем самым структуру БД... Но, говорят, работает :)
un1t: я вас понимаю и даже согласен в некоторых моментах, о чем писал выше, но хочу кое-что подчеркнуть касательно "django vs flask".
Давайте отдельно про ORM, т.к. это, можно сказать, ядро, все основные операции и плюшки так или иначе крутятся вокруг нее.
SQLA - это:
1) data mapper
2) отдельное комьюнити, отдельная разработка, в отрыве от каких-либо фреймворков
Django ORM - это:
1) active record
2) пилится вместе с фреймворком, общее коммьюнити
Отсюда автоматически следует, что SQLA мощнее, by design.
Есть некоторая часть, где data mapper и active record пересекаются: простые и относительно простые запросы, типовые задачи. И да, django orm отлично подходит для таких задач. НО их можно решить с помощью SQLA не хуже, а даже более прозрачно: явные ключи, явные join, явный group_by, явная и повсеместно используемая сессия. Это выглядит тяжелее, но ничего не скрывает от разработчика и не отрывает от структуры БД настолько сильно, насколько это делает active record, что очень важно с философской точки зрения: меньше шансов написать ненормализованную БД или пойти против реляционной теории. Если речь идет о кастомном проекте, нетипичном, то такая особенность SQLA будет плюсом.
Они не взаимозаменяемы на всем множестве задач. Django ORM - это, грубо, подмножество SQLA, отсюда плюс - проще, но минус - менее прозрачна, меньше умеет.
Кроме адовых запросов, существуют не адовые: например, мы не можем сделать простой LEFT OUTER JOIN с кастомным условием. Да, 2 запроса могут быть быстрее, особенно, если использовать кэш, но это уже конкретные костыли под задачу. Ведь у нас есть такой инструмент как JOIN из реляционной алгебры, в теории этот запрос быстрее двух отдельных, значит, его надо использовать. И, скорее всего, так и будет на большинстве проектов, если речь не идет про высокие нагрузки, где рушатся традиционные походы (и вообще питон в силу своей интерпретируемой природы). stackoverflow.com/questions/6500066/annotating-a-d... - вот эта задача, кстати. Вполне типовая, как по мне. Вообще, джойны точно слабое место в django orm, а вот в sqla есть на любой вкус.
Еще нет, например, сложных первичных ключей. https://code.djangoproject.com/wiki/MultipleColumn... Но, видимо, скоро будут. Опять же реляционная теория их поощряет: нужно меньше памяти (-1 лишний суррогатный индекс), но с другой стороны растут в размере внешние ключи. Поэтому использование таких ключей - это холиварный вопрос. Но если у меня, допустим, одна таблица, где есть естественный первичный ключ из двух столбцов, то почему нет?
Это, пожалуй, основное (исходя из моего опыта). Уверен, что если заморочиться, то в сложной модели БД можно найти много запросов, которые нельзя описать с Django ORM, это следствие просто из дизайна. Можно попробовать покопать еще в group_by-запросы, там точно что-то должно найтись.
Подобные ограничения есть во всей джанге вообще. Даже админка тотально повязана на CRUD и если захочется что-нибудь, что не дублирует БД, а полное ajax'а и "мало кликов" (например, удобное представление ациклических графов), то придется очень много писать с нуля, по времязатратам приблизится к Flask, но с меньшей свободой.
Я давно не делал коммерческих типовых проектов на Flask, потому что это значительно сложнее, ушел с него. И разделяю вашу любовь к Django и подтверждаю, что она подходит для типовых задач. И если ее очень любить, то она подходит для чего угодно, как и если очень любить PHP, то он будет удобнее всех наших с вами питонов.
Но стоит признать, что в целом, в теории, на всем множестве задач найдется то, что сделать проще с более низкоуровневыми инструментами.
Это как коробка-автомат. Она же более унылая, я хочу переключать передачи, чувствовать двигатель. Любой автомат by design более унылый. Но для 95% времени в городе с ним будет удобнее. Зависит от задач. Но нельзя сказать, что механика - костыли, хотя она может быть и медленнее.
svg blur/css filter работают хорошо, но ведь нет возможности заблюррить то, что находится под div? Нужно костылять. То есть задача, которую решает автор, не решается с помощью этих инструментов в лоб.
А так присоединяюсь. Отказываться от этой идеи лучше.
un1t: я немного вас перефразирую. Вы пишете "если запрос в джанго орм не уместился => костыль", отсюда следует, что "если запрос в джанго орм не уместился, но уместился в sqla, то sqla позволило сделать костыль" и, обобщая, "sqla не нужен, а если нужен, то это костыль". Гы-гы.
Я в принципе все написал в предыдущем комменте, если его снова перечитать, то это будет ответ и на ваш текущий.
Поддерживаю, но с оговорками. SQLA быстрее и мощнее, как и Jinja. Чтобы было понятно, что паттерн SQLA (datamapper) сам по себе шире/мощнее, чем activerecord (django orm), тут не нужен никакой холивар, если что. Простой пример: в джанге нельзя сделать даже явный джоин, а поэтому написать сложный запрос бывает затруднительно. Конечно, да, надо тестить скорость, смотреть, как лучше обработать (в бд или на бэке), но в целом я про архитектуру и возможности. Прямой доступ к сессии, явные ключи. Про шаблонизатор то же самое. Пример: нет макросов, нельзя просто без фильтра извлечь что-то из dict. Конечно, да, есть сниппеты, но я опять же в целом про архитектуру. Это можно долго продолжать.
Но в 99% джанга будет комфортнее, проще и ее хватит с лихвой. Самая большая печаль фласка - это отсутствие админки. Да, есть flask-admin, но ее поддержка на реальных проектах у меня отъедает раза в 2-3 больше времени, чем админка джанги. Фласк идеален, но для API и чего-нибудь масштаба сайта-визитки, либо для очень-очень кастомного огромного проекта. Это минимализм, а за него всегда надо платить.
Ах да, я еще однажды попал в жесть при переходе на 3 питон на фласк-проекте, там просто половина расширений отвалилась, а когда присмотрелся - они уже заброшены разработчиками. В итоге фиксил вручную, кажется, все еще работает.
Поэтому если вообще возник вопрос Django или Flask, то Django. Тот, кому нужен Flask действительно, такое не спрашивает. :)
Я люблю оба фреймворка, но не думаю, что сравнивать вплотную их сильно корректно, ибо все-таки фласк - это микрофреймворк.
Вы тут куда-то подевали дефолтовую таблицу main... И потом продублировали ее записи в gw1 и gw2, так, конечно, можно, но почему, смысл?) Также см. мой ответ (https://toster.ru/answer?answer_id=572523) на другой ваш вопрос, должно пролить свет на "но с сорцом второго". Также вы указали SNAT для всех интерфейсов и еще и равный адресу шлюза... Советую почитать LARTC (lartc.org/howto) и iptables docs (www.opennet.ru/docs/RUS/iptables).
А что сложного в бинд? 1 конфиг (дефолтовый практически не требует допилов, разве что ограничить, кому передавать зоны, кто может совершать рекурсивные запросы и т.п.), шаблонные файлы зон, которые вы уже заюзали в NSD. В итоге добавление домена - это 2 минуты: добавить пару строчек в named.conf, скопировать зону с имеющегося домена, релоаднуть демон. Мне всегда казалось, что проще и не бывает :)
jsfiddle.net/4hd9qjLq