Роман, да, печаль. Во многих таких отношениях есть "сильная" и "слабая" сторона, и "слабой" обычно приходится соглашаться на требования и условия "сильной". Например, если это какой-то крупный продавец канцелярки тысячам организаций, то вряд ли он будет согласен сделать кастомный договор покупателю 10 пачек бумаги...
Или нанимать только людей, которые осознают свои действия (и не качают готовые файлы договоров из интернетов), или отказаться уже от ручных договоров и завести себе CRM.
mag1chka, есть два способа: либо загружают видео в саму телегу и отдают пользователю на просмотр (он смотрит из телеги), либо показывают сайт/webapp с каким-нить кодиком и рекламой.
В обоих случаях бот может получить страйк.
К кодику и некоторым другим пиратским cdn потенциально можно подключиться бесплатно, условия они расскажут, если к ним обратиться. Но юзерам приятнее смотреть из самой телеги. А это надо загружать файлы заранее.
Если залогиниться и видео проигрывается, то можно смотреть даже несмотря на бан. В качалку можно подсунуть куки, но тогда бан может стать персонализованный.
Некоторые сети превентивно забанены в ютубе, дело даже не в твоей личной качалке. Например, сети крупных датацентров.
agpecam, нет, это всё ещё говно. Тем более что я не уверен, что в Linux это будет нормально работать. В конце концов, я сталкивался с живой ситуацией, когда на винде кривая конфигурация сети спасалась через proxy arp на шлюзе, а на Linux в той же сети ни хрена не работало. Может, если попрыгать с бубном вокруг sysctl, оно бы и заработало, но это всё с самого начала было ненормально и надо было исправлять, а не обкладывать ещё большим количеством костылей.
Тем более предложение бегатьп по всем хостам в сети и вручную пропихивать им кривые роуты. В нормальной сети вообще нормально использовать DHCP.
Это так и не будет работать. Ты пытаешься обойтись средствами 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%, и куча приложений начинает жутко колбасить. Потому что они-то уж точно уверены, где и что и какого размера находятся, используя абсолютное позиционирование всего и вся.
Такая же проблема бывает и на современных телефонах. Мобильные оси, конечно, формально умеют в масштабирование, но потом самые заурядные приложения начинают вести себя непредсказуемо.
Так что лучший путь тут - не использовать масштабирование вообще.
