EvgMul, замените left join на просто join или inner join - тогда будет полное пересечение 3 таблиц. Записи main_id которых нет хотя бы в одной таблице не будут участвовать в запросе.
mike89klein, Увидел изменение поста.
Добавьте опцию push redirect-gateway def1 bypass-dhcp в ccd нужных клиентов.
А затем на фаерволе ВПН сервера блокируйте адреса клиентов для выхода в интернет, как советовал ky0
Strannyk, Я не шеф, чему и рад вполне. Статистику не вел, но подтвердить ваше высказывание не могу. Yustas Alexu, Вы передергиваете и преувеличиваете. Я ничего такого не писал. Вы не согласны, что работодатель в праве предъявлять сотрудникам некоторые требования? Например, что сотрудник должен делать работу, за которую ему платят, NDA, да тот же режим работы в конце концов - это то же требование работодателя.
Без понятия. Я достаточно быстро адаптируюсь.
Многие процессы в организме перестраиваются в течение 3 недель. Так что за 3 недели постоянной тренировки по идее можно адаптироваться. Но конечно все индивидуально - 3 недели это в среднем по больнице.
Кстати, желание на выходных отоспаться приводит к тому, что в понедельник не можешь проснуться во время :) Так что отсыпаться можно, но не слишком долго.
Когда адреса закончатся - услуга по покупке белых ip будет недоступна.
Это не технический вопрос, а юридический. Провайдер не может продавать услугу, которую не в состоянии исполнить. Иначе провайдер скоро перестанет существовать.
Когда вы покупаете (арендуете) белый статический адрес, этот адрес закрепляется за вами на оплаченный период времени (не особо важно как это реализовано технически). Если бы это было не так, то в интернете был бы полный бардак.
Шеф вам платит зарплату - имеет право выставлять требования.
В конце концов - шеф один, а вас целая пачка и у каждого свои закидоны. Шеф не может подстраиваться под всех. Поэтому планерка всегда будет в удобное для шефа время.
Иногда проще начать работу в обед и продолжить до ночи, а потом утром выспаться и с хорошей работоспособностью отработать свою смену.
Это самообман. Вы закончите работу ночью - на следующий день не выспитесь и либо встанете утром и начнете невыспатый пытаться работать, либо забьете и проваляетесь в койке опять до обеда. Первый вариант более тяжелый, но правильный. Второй вариант - либо все равно придется когда-то ломать, либо полностью переходить на работу со второй половины дня.
То что реально работает - это жесткий график для работы. И не важно какой у вас природный режим - организм постепенно перестроится и вы привыкните к любому режиму, главное что бы режим был постоянным.
Удаленка позволяет не ломать организм и работать в привычном режиме, когда тебе это комфортно, но график должен быть постоянным. Иначе комфортного режима не будет никогда.
На счет трекеров и скриншотов - это идиотизм. Если сотрудник не выполняет свою работу (а это рано или поздно выяснится без трекеров), то зачем держать такого сотрудника?
Mars36, Юникод бывает разный: UTF8, UTF16, UTF32 и это только наиболее распространенные варианты и то есть еще и "подвиды". Какой конкретно юникод у вас подается на вход?
Я подозреваю юникод у вас подается в программу из файла с помощью перенаправления stdin.
Тогда можно при вводе в принципе не привязываться к кодировке консоли. Кодировка важна, только когда вы что-то выводите на экран (чтоб правильно отображались символы) или когда начинаете сравнивать 2 строки (они должны быть в одной кодировке).
Вы можете просто прочитать входную строку. При этом не важно какая кодировка консоли будет - прочитается ровно то что будет подано на вход. Вы же читаете не сами символы, а коды символов, коды будут те что были поданы на вход. Кодировка это лишь интерпретация кодов.
Входная кодировка у вас известна. Можно просто применить функцию перекодировки (или парную ей) в требуемую вам кодировку.
В качестве входной кодировки указывайте не ту, что установлена в консоли, а ту что вам известна априори.
Или вы можете внутри программы использовать ту же кодировку, которую ждете на входе. Тогда можно вход не перекодировать.
Выходные сообщения и параметры командной строки потребуется перекодировать, если внутренняя кодировка отличается от кодировки консоли.
Но если входные условия изменятся, например входной файл будет закодирован в другой кодировке, или вместо файла придется читать консольный ввод, то придется модифицировать код. Что бы этого избежать есть смысл в параметрах задавать входную кодировку.
В реальной сети нужно ждать данные функцией select.
Если вы в select() просто бесконечно ждете, когда данные появятся на сокете, а затем вызываете recv(), то чем использование select() отличается от простого вызова recv(), который то же ждет данных?
select нужен, там где он нужен. Например, когда вы пишете асинхронное приложение и у вас 100500 сокетов для опроса, или когда вы пытаетесь между получением данных делать какую-то другую полезную работу в том же потоке. Если ничего этого нет (как в нашем примере), то использование select избыточно.
На счет возвращения нуля в recv(), вам уже ответил galaxy
Dubrovin, Все перечисленные вами сервисы не раскрывают деталей реализации. Потому схема и эксклюзивная - каждый из этих сервисов лабал какой-то свой вариант.
Не встречал описания настройки подобного сценария. Но не вижу особых проблем в реализации с использованием открытых инструментов.
Реализуете - напишите небольшой мануал и выложите в интернет. Схема перестанет быть эксклюзивной :)
Dubrovin, Ваша схема сильно эксклюзивная. Вряд ли вы найдете мануал для настройки именно такой схемы.
Но все составляющие достаточно простые и легко гуглятся: настройка openvpn сервера для клиентов с фиксированными адресами (если решите использовать вариант с 32 ВПНами, то понадобится запустить 32 экземпляра openvpn с разными конфигурациями), правила forward для iptables
BMinhoj, У вас выводятся странные знаки, потому что ваши переменные s,d,f,b имеют тип char и стандартная библиотека пытается честно вывести какой-то символ. А вам нужен не символ, а число. Просто преобразуйте перед выводм char в uint32_t. Или сразу эти переменные делайте uint32_t.
RST001, Книг не посоветую. У меня не было опыта в написании сетевых драйверов под линукс. Был опыт под QNX. Но уверен, что принципы в линукс примерно аналогичные.
Сокеты Беркли - это пользовательский уровень. Драйвер не работает в этих терминах. В драйвер будет приходить просто буфер на отправку. Точно так же вы должны используя API передать полученный буфер на вышестоящий уровень. Вот и все. Никаких сокетов.
Берете существующий драйвер и переделываете его под свое железо. Какие у вас "конкретные нужды"? Для сетевых Ethernet адаптеров все нужды одинаковые, отличаются только железные реализации. Проще всего найти драйвер для железки того же производителя, что и ваша, и переделывать его. В этом случае, вероятно, изменений будет не много.
Кстати, если есть драйвер с открытыми исходниками под другую ОС, то возможно будет проще адаптировать его под Линукс, чем менять драйвер от другой железки.
Я сам писал драйвер именно таким образом. Из всей литературы у меня была только небольшая обзорная статья в документации ОС по этой тематике с примером "виртуального" драйвера, несколько вариантов драйверов под другие железки для QNX и драйвер под мою железку для Линукс. В общем из всего этого конструктора собираешь свой велосипед.
Операторы никогда не гарантируют скорость до конечной точки трафика (это просто не возможно).
Они гарантируют только скорость от клиента до собственного оборудования ("последняя миля"). А дальше - как повезет. И это касается всех операторов, не только в РФ, но и во всем мире.