1) поэтому возможность отказаться от фильтра по ip.
2) ну а по домену вы в принципе не ограничите. Нет такого поля в L3. Только в варианте с callback'ом, который весьма сложнее для реализации клиента.
L2, L3 - уровни OSI
Нет, скайпа нет. Что там в виндах - понятий не имею, не пользуюсь.
Дальше колупать в... За давностью лет даже не помню, как такое у гугла спрашивать. Попробуйте погуглить simple linux router, linux home gateway
В общем нужны /proc/sys/net/ipv4/ip_forward и iptables с MASQUERADE
> инет есть на той машине где мост создан, а на той машине куда он должен раздаваться по eth1 - нету
> прямое подключение, привязанное к маку сетевой
Видимо, ваш провайдер отфильтровывает пакеты с MAC-адреса машины, подключенной физически через eth1.
На всякий случай: вы L2 от L3 отличаете? Мост и роутер не путаете?
Ваши комментарии позволяют предположить, что вы хотите сделать роутер, но зачем-то полезли делать мост.
Что-то вроде этого.
Можно порезать на json документы и пихать их в какой-нибудь mongodb или ещё что-нибудь документо-ориентированное. Или в jsonb postgresql.
Можно нормализовать в реляционную базу. Получится более строгая схема.
Не знаком с вашей предметной областью, но разве в суде судья всегда только 1? Коллегиальные суды не рассматриваете?
Да, придётся парсить эти данные по всему массиву документов. Перебрать лям документов раз в год по требованию - это принципиально не то же самое, что перебирать лям документов в рантайме.
Это самая малая из предстоящий проблем, чистое машинное время, да и то не слишком большое. Миллион документов не так и много. Хотя, конечно, в зависимости от документов и как вы их разбор реализуете.
По граблям "в этих документах 'Судья на заседании', в тех - 'Судья'" или "здесь Иванова А.А., там А.А. Иванова, а сям - полностью ФИО" и ещё каких-нибудь вариациях пока не ходили, что ли? Якобы типовые документы нормализовать до на самом деле стандартной формы бывает не просто. А то ещё выходит распоряжение, и до такой-то даты по одной форме пишется, потом по другой, потом по третей. Тут имея вагон времени разобрать трудоёмко, а вы в рантайме хотите.
Sushkov: , а вы про вырожденный случай, когда весь конструктор в потомке - это parent::__construct(); и больше ничего? На этом стоило заострить внимание в вопросе. Да, такой конструктор не делает ничего полезного.
По скрину cpu-z видно, что память завелась в двухканальном режиме на 800мгц и CL10.
А это наименование планок памяти, как их видит софт. И, судя по всему, в скобках указаны их дефолтные настройки.
К текущим параметрам отношения не имеет. Если вы разгоните процессордо 4ггц, он не перестанет определяться как FX-8320
Immix: если вы вручную указали частоту 1600 и машина стартовала аж до уровня "загрузить ОС" - почему нет? Можете дополнительно проверить во вкладке memory cpu-z
Значит на этой машине порт занят. Попробуйте с другим локальным адресом (я только постоянно забываю, это порт до ip или после, вроде бы до). Если пути в этом веб-интерфейсе захардкожены на именно этот порт, то тогда ищите другую машинку с браузером, на которой этот порт свободен.
Александр Булгаков: RFC написаны с исходной точки character = octet = byte
> That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@")
И так далее. Для ASCII это справедливо. Для всего остального - когда как.
Да, я исходил из предположения, что в таблицу сохраняются данные каждый день для всех, у кого exp != 0. Если какого-то дня не было - значит пользователь на тот момент не был зарегистрирован вообще или имел 0 exp.
Для таблицы такого плана, да если ещё и партицировать - и сотни миллиардов строк фигня. Зато считать проще и быстрее.
CURRENT_DATE - странно, но да, мог чего-нибудь напутать.
Вполне. Могут быть вариации, но суть схожа. Например, система А отправляет событие, система Б генерирует id транзакции. Следом система Б обращается к системе А с вопросом: вот по такой-то транзакции запрос выполнять? Соответственно, А может удивиться "не знаю такую транзакцию"
Есть огромный бонус в том, что архитектурно предусмотрена суровая реальность - что делать, если система Б случайно упала. Ничего не делать, как поднимется - так и получит штатно все пропущенные сообщения.
Но это всё-таки сценарии не атомарные. Некоторое небольшое время Б может быть закоммичено, а А - ещё в процессе или наоборот. Eventual consistency т.е.
Если нужно именно закоммитить распределённую транзакцию - то посмотрите в сторону двуфазного коммита. Помнится, там ворох своих граблей.
2) ну а по домену вы в принципе не ограничите. Нет такого поля в L3. Только в варианте с callback'ом, который весьма сложнее для реализации клиента.