Иногда проще начать работу в обед и продолжить до ночи, а потом утром выспаться и с хорошей работоспособностью отработать свою смену.
Это самообман. Вы закончите работу ночью - на следующий день не выспитесь и либо встанете утром и начнете невыспатый пытаться работать, либо забьете и проваляетесь в койке опять до обеда. Первый вариант более тяжелый, но правильный. Второй вариант - либо все равно придется когда-то ломать, либо полностью переходить на работу со второй половины дня.
То что реально работает - это жесткий график для работы. И не важно какой у вас природный режим - организм постепенно перестроится и вы привыкните к любому режиму, главное что бы режим был постоянным.
Удаленка позволяет не ломать организм и работать в привычном режиме, когда тебе это комфортно, но график должен быть постоянным. Иначе комфортного режима не будет никогда.
На счет трекеров и скриншотов - это идиотизм. Если сотрудник не выполняет свою работу (а это рано или поздно выяснится без трекеров), то зачем держать такого сотрудника?
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 и драйвер под мою железку для Линукс. В общем из всего этого конструктора собираешь свой велосипед.
Операторы никогда не гарантируют скорость до конечной точки трафика (это просто не возможно).
Они гарантируют только скорость от клиента до собственного оборудования ("последняя миля"). А дальше - как повезет. И это касается всех операторов, не только в РФ, но и во всем мире.
RST001, Сам по себе MDIO - это стандартизированный интерфейс/протокол обмена запросами/ответами ЦПУ и PHY.
Запросы это просто прочитать/записать регистр PHY для некоторого порта.
Но возможности у разных реализаций PHY разные. Регистры PHY стандартизированы лишь частично. Поэтому в зависимости от PHY возможности программного управления могут быть разными.
При этом API MDIO меняться не будет, будут меняться только номера регистров и поля в этих регистрах.
Тут еще замешалось что-то связанное с тем, что struct test.i - это массив. Если убрать массив из структуры и сделать просто int, например, то поведение изменится.
Там столько труда нужно приложить чтобы все сделать какой то упаковщик
Так и есть. Если производитель не позаботился, то сделать свой собственный repack с возможностью тихой установки для сколько-нибудь сложного ПО - это может быть достаточно не тривиальная задача.
Другое дело, что обычно для сложного ПО есть подобные возможности.
но у меня и без него работает эта функция из synchapi.h
Я и писал, что можно инклудить synchapi.h или выдернуть оттуда объявление функции.
Собственно, зачем ты инклудишь какие-то заголовки - затем, что там содержаться предварительные объявления функций (не только они естественно). Ты запросто можешь не использовать заголовочный файл, а сам в собственном коде сделать это предварительное объявление.
Ты может спросишь: "Зачем компилятору нужны эти предварительные объявления"? Они нужны потому что компилятор должен сформировать правильный код вызова функции: положить в стек в правильном порядке нужного типа аргументы функции, возможно, с предварительным приведением типов, а так же получить возвращаемое значение функции правильного типа.
Тут стоит понимать, что компилятор С++ при компиляции файла исходного кода никогда не заглядывает вперед по файлу (или проекту), поэтому все сигнатуры функций (и типы данных) должны быть известны до первого использования в коде. Так же при компиляции проекта, состоящего из нескольких файлов, каждый файл компилируется отдельно и в этом процессе компилятору не известно, что у тебя там в соседних файлах.
Кстати, в языке Си существует такой странный анахронизм - если для функции нет предварительного объявления, то компилятор считает, что эта функция принимает один параметр типа int и возвращает то же int. Т.е. там можно вызывать любую функцию без предварительного объявления. Но это не значит, что это будет правильно работать, если реальная сигнатура функции отличается от "умолчальной". Но вызвать можно. Интересно, эту баго-фичу случаем не пофиксили в последних стандартах?
samokiller, В дополнении ко второму варианту - QUIK можно запустить под Linux под wine. В этом случае не придется платить еще и за аренду винды. Работает вполне нормально. Правда местами шрифты криво отображаются кракозябрами - в окне со всплывиющими сообщениями. Но в остальном все нормально.
Не разорвется, если ВПН клиентом будет роутер, а не компьютер с QUIKом.
Может разорваться только по таймауту.
Кстати, второе предложение (QUIK на VPS) годится. Только надо продумать схему, чтоб ключи не хранить на VPS. И стоить аренда такого VPS будет больше, скорее всего.
dR2nrWs5TC, Зря ты кипятишься. Ссылка нормальная, все для создания нового проекта там написано. Если у тебя что-то не выходит - задавай более конкретные вопросы.
Сначала я написал ответ, а потом посмотрел ссылку. Если бы раньше посмотрел, то ответ, пожалуй, и не писал бы.
Это самообман. Вы закончите работу ночью - на следующий день не выспитесь и либо встанете утром и начнете невыспатый пытаться работать, либо забьете и проваляетесь в койке опять до обеда. Первый вариант более тяжелый, но правильный. Второй вариант - либо все равно придется когда-то ломать, либо полностью переходить на работу со второй половины дня.
То что реально работает - это жесткий график для работы. И не важно какой у вас природный режим - организм постепенно перестроится и вы привыкните к любому режиму, главное что бы режим был постоянным.
Удаленка позволяет не ломать организм и работать в привычном режиме, когда тебе это комфортно, но график должен быть постоянным. Иначе комфортного режима не будет никогда.
На счет трекеров и скриншотов - это идиотизм. Если сотрудник не выполняет свою работу (а это рано или поздно выяснится без трекеров), то зачем держать такого сотрудника?