Это так и не будет работать. Ты пытаешься обойтись средствами L2, а тебе надо L3. Между подсетями должен быть маршрутизатор (или хотя бы свитч с поддержкой L3-функций, фактически "упрощённый маршрутизатор").
В данном случае надо сделать так:
vlan1 - 172.19.2.0/23
vlan2 - 172.19.4.0/23
В идеале все линки между свитчами сделать trunk, на каждом свитче сделать vlan1 и vlan2 и включить в каждый из них нужные порты как access с нужным vlan (в левой части сети vlan1, в правой vlan2 - но с такой архитектурой можно будет любой порт в любом свитче включить в любую из подсетей).
Между свитчом 1 и сервером сделать тоже trunk. На сервере поднять вланы, сделать два интерфейса eth0.1 и eth0.2 (если это Linux, то интерфейсы могут получить имена примерно такого типа, в других осях может быть иначе). На каждом интерфейсе поднять адрес в своей подсети. Например, 172.19.2.1 и 172.19.4.1. Вот по этому адресу из этих подсетей сервер и доступен. Можно также эти адреса использовать как шлюз - тогда и по другим адресам сервера он будет доступен. Например, по адресу 172.19.0.1.
Yulia2604, мы ответим такими же общими фразами. Мы не знаем, насколько Viber бэкапится в iCloud и как проверить, забэкапился ли он в данном конкретном случае.
Follin, сомневаюсь, что кто-то так заморачивался. Если речь идёт об эпизодически запускаемых приложениях, можно просто менять разрешение перед их запуском и менять обратно после. В том числе можно сделать скриптики, которые будут с помощью xrandr менять разрешение и запускать их для удобства по необходимости.
pavlik 322, так как в телеге можно авторизоваться чисто по номеру телефона и получить доступк переписке, значит, если что-то там и "зашифровано", то ключ хранится где-то там же на сервере. Это так же безопасно, как запереть дверь, а рядом повесить ключ на гвоздик...
У WA, судя по заморочкам с "резервными копиями" при авторизации с нового устройства, шифрование, возможно, таки есть. Но сложно гарантировать, что они там "на всякий случай" не хранят твой ключик втихаря или не внедряют MITM в коммуникацию в нужный момент, в том числе "по запросу" тех, "кому это надо".
Для настоящего E2E надо обменяться ключами шифрования или хотя бы их отпечатками за пределами самой инфраструктуры мессенжера/почты.
Lynn «Кофеман», кстати, я пользовался и с одним бывшим коллегой переписка у нас шифровалась. Но это было недолго, потому что случился 22 год, он уволился и уехал в Германию.
Lynn «Кофеман», Thunderbird поддерживает. Раньше с помощью раширения Enigmail, сейчас нативно. При включении и правильной настроке этого на адрес, от которого известен открытый ключ, будет отправлено зашифрованное письмо. Которое получатель без ключа не прочитает.
Проблема в том, что большинство разработчиков приложений игнорируют системное масштабирование, системный dpi итд и полагаются на дефолтное поведение системы и компоновку элементов по умолчанию. Это ещё в Windows 95 было: ставишь скейлинг, отличный от 100%, и куча приложений начинает жутко колбасить. Потому что они-то уж точно уверены, где и что и какого размера находятся, используя абсолютное позиционирование всего и вся.
Такая же проблема бывает и на современных телефонах. Мобильные оси, конечно, формально умеют в масштабирование, но потом самые заурядные приложения начинают вести себя непредсказуемо.
Так что лучший путь тут - не использовать масштабирование вообще.
iysam, есть много узких мест в интернетах. Вплоть до ёмкости магистралей этого провайдера до твоего города, особенно если это не столица или какой-то из миллионников.
Видимо, берётся ссылка уже с sessid в GET-параметрах и открывается в инкогнито? А после перезагрузки страницы битрикс сбрасывает этот sessid редиректом?
c17killer, в том-то и крутость телеги и библиотек для Bot API, что между поллингом и вебхуками переключение очень легко организовать. Можно отлично отлаживаться на поллинге, можно небольшие проекты вообще на нём и оставлять и можно не испытать проблем потом при переходе на вебхуки.
Елисей Константинов, нет, никому не должно. Решение о приёме в кодовую базу Debian принимают в Debian, там и надо спрашивать. Но я сомневаюсь, что это им там нужно. То, что даже сборка этого старья требует усилий, очень хорошо характеризует реальную востребованность.
В данном случае надо сделать так:
vlan1 - 172.19.2.0/23
vlan2 - 172.19.4.0/23
В идеале все линки между свитчами сделать trunk, на каждом свитче сделать vlan1 и vlan2 и включить в каждый из них нужные порты как access с нужным vlan (в левой части сети vlan1, в правой vlan2 - но с такой архитектурой можно будет любой порт в любом свитче включить в любую из подсетей).
Между свитчом 1 и сервером сделать тоже trunk. На сервере поднять вланы, сделать два интерфейса eth0.1 и eth0.2 (если это Linux, то интерфейсы могут получить имена примерно такого типа, в других осях может быть иначе). На каждом интерфейсе поднять адрес в своей подсети. Например, 172.19.2.1 и 172.19.4.1. Вот по этому адресу из этих подсетей сервер и доступен. Можно также эти адреса использовать как шлюз - тогда и по другим адресам сервера он будет доступен. Например, по адресу 172.19.0.1.