mayton2019, По моему, вопрос парадигм вообще чисто теоретический. По крайней мере, я не сталкивался с обсуждением в какой парадигме делать проект или чтобы где-то следили именно за соблюдением парадигмы. Частая практика, когда парадигмы смешиваются в рамках одного проекта. Заказчику же главное, чтоб программа выполняла свою задачу без ошибок и с приемлемой скоростью.
Мой первый комментарий был о том, что понятия парадигм вполне себе актуальны и парадигмы есть в реальном коде. Но это не принципиальный вопрос. Парадигмы это не догма, их можно применять по отдельности или смешивать, там где ты считаешь это нужным. Выбор всегда остается за программистом.
Писать не используя парадигмы можно, но только очень простые приложения. Сейчас эти понятия уже настолько въелись в подкорку, что чтобы намеренно отказаться от них придется постоянно контролировать себя не скатится в парадигмы :)
mayton2019, Вполне поверю. Ядро линукс - сложное, конечно, и там как минимум процедурный и структурный подходы имеют место быть, но, я думаю, можно легко найти и ООП в каком-то урезанном виде (даже с учетом того, что Си не ООП язык) и может даже функциональщину, но тут не уверен. Хотя и goto там употребляется повсеместно, что противоречит структурному подходу.
Примеров ООП из ядра с ходу не приведу, а лезть в исходники лень.
mayton2019, Все правильно. Но это никак не отменяет наличие парадигм. Ты можешь их использовать даже ничего не зная о их существовании.
В любом случае та или иная парадигма будет использована (или какое-то их подмножество), т.к. без этого практически не возможно сейчас написать ни одно мало-мальски сложное приложение. А, например, структурные принципы можно применять в рамках одной функции, почти не зависимо от ЯП.
Чисто теоретически:
Возможно стоит поиграть с приоритетом приложения. Запускайте ваше приложение с повышенным приоритетом. По идее, после установки патча должны добавится дополнительные приоритеты. Возможно вместе с патчем идут дополнительные утилиты, позволяющие использовать новые приоритеты.
Загрузка ЦП все равно имеет значение. Например, если у вас будет запущено несколько приложений с повышенным одинаковым приоритетом, то они начнут бороться за ЦП между собой и если ЦП будет не хватать, то все - реального времени не будет.
XR699ew, Например, если DNS сервер не доступен - без этой опции команда будет выполняться дольше, пока у нее не произойдет отлуп DNS запроса по таймауту.
Кроме того, часто нужен именно IP адрес, а не имя.
Подобная опция обычно есть во всех низкоуровневых сетевых инструментах, типа ping, netstat и т.п. Она может называться по другому, но смысл тот же.
Но он же мне заблокирует консоль, или это запускает как-то иначе?
Откройте другую консоль. Даже если линукс без GUI, то там по умолчанию есть несколько терминалов и их количество можно настроить, между терминалами можно переключаться.
Кроме того никто вам не запрещает в одном терминале использовать какой-нибудь тайловый менеджер (tmux и т.п.)
Кроме того, добавьте амперсанд в конце команды и команда будет выполнятся фоном, сразу же освободив терминал. Но это может быть не удобно, если у фоновой задачи много вывода в консоль.
В общем учите мат.часть. Это все базовые знания о работе в линукс.
На счет устаревших понятий не согласен. Эти понятия описывают то, что используется на практике.
Другое дело, что на С++ (так же как и в других языках) вполне можно применять все парадигмы и это не делает их устаревшими.
Подойдет любое введение в ассемблер - там научитесь компилировать, поймете базовые принципы, ...
А дальше по любому Intel64 Developer Manual, ну или какой там у вас проц.
При программировании на ассемблере без документации производителя процессора не обойтись, любая книга будет только введением в тему. Не стоит ожидать от печатных книг по ассемблеру полноценного охвата темы.
Судя по всему вы имеете смутное представление о программировании.
Qt - это библиотека (фреймворк) для разработки приложений на С++.
Похоже, вам нужно сначала озаботится базовыми знаниями С++, что бы понять как программировать на этом языке. А затем вы уже сможете перейти к Qt. Без знания С++ в Qt вам делать не чего. Начинать надо с консольных приложений, т.к. это самый простой вариант.
По С++ и по Qt есть хорошие толстые книги.
1. В psexec пути задаются относительно того компа, на котором запускается программа. Если путь сетевой, то пользователь, из-под которого удаленно запускается программа, должен иметь доступ к сетевому ресурсу. В этой части у вас вроде все нормально.
2. Т.к. вы запускаете скрипт (батник), то в psexec вы должны запускать не его, а cmd.exe и передавать путь к батнику как параметр cmd.
3. В винде действует UAC. Он действует и на программы, запускаемые удаленно. А значит, даже если вы запустили программу из-под админа, то программа должна запросить повышение привилегий..
У psexec вроде есть ключ для запроса повышения привилегий, посмотрите справку.
Действие UAC можно отключить для удаленно запускаемых программ через реестр:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy = 1
Если параметра нет, то его надо создать, тип параметра REG_DWORD.
После правки реестра необходимо перезагрузить комп. Править надо реестр только компа на котором должна удаленно запускаться программа.
4. В psexec так же есть ключ, который позволяет сначала скопировать запускаемую программу на удаленный комп, а потом ее запустить. Но т.к. вы запускаете скрипт, то, видимо, этот ключ в вашем случае не сработает.
Для отладки работы psexec лучше начать с какого-то простого батника, не требующего прав админа, такого, чтоб на экране было видно, что он работает (например выводите какое-нибудь сообщение с помощью echo). Положите батник на локальный диск удаленного компьютера и пытайтесь его запустить удаленно.
После того как это получится, переложите батник на сетевой ресурс - и то же самое.
А дальше переходите к вашему реальному батнику и поиграйте с повышением привилегий.
Кстати, запускать удаленно программы по моему можно с помощью wmic, погуглите. Но там действуют все те же правила, что и для psexec, так что разницы особой нет. И, наверное, тот же powershell то же умеет удаленно запускать программы.
Ikarchik, Оно может и не помогло, но по крайней мере так правильно, если не врет ваша ссылка.
А так как вы делали до того работать и не должно.
Тут еще вопрос в том, какой режим поддерживает ваше устройство. Теоретически, наверное, может поддерживать оба режима и даже некоторое автоопределение режимов, но это не точно. По уму, надо смотреть описание устройства, там все должно быть сказано. Но т.к. это китайская поделка, то надежды и на это мало.
Из собственного опыта - в profibus, например, только один режим работы 8E1 и это зафиксировано в самом стандарте, на слейвах, как правило, автоопределение скорости передачи и список скоростей фиксированный и, по большей части, не совпадает со стандартными скоростями в винде и линухе.
Получается, что у вопрошающего китайское реле не совмещается с китайским же переходником?
Получается. Предполагаю, что в реле реализованы более жесткие требования к RS485. А переходник - общего назначения. Когда столкнулся сам с подобной проблемой полез читать отзывы на товар у продавца и там то же было сообщение, что с устройствами пром.автоматизации переходник не работает. Это меня и натолкнуло на мысль попробовать заменить переходник.
Судя по вашей ссылке modbus работает в режиме 8N2 или 8E1, но не 8N1 - это важно, т.к. протокол рассчитан на 11 битный байт, а в 8N1 байт будет содержать 10 бит при передаче.
Пытался таким же переходником RS485-USB с алика (визуально точно такой же) работать с Profibus устройствами - не вышло. Либо ведомое устройство молчит, либо получаю мусор (зависело от ведомого устройства). При этом если объединить 2 таких переходника друг с другом - данные передавались нормально.
После того как заменил переходник на Moxa UPort 1250 все сразу же заработало.
Alewenka, Потому что в документах (doc/xls) могут быть макросы, которые могут быть исполнены при открытии автоматически. Макросы могут содержать зловредный код.
В картинках и прочих файлах нет исполняемого кода. В этом случае используют другой подход - ищут баги в приложениях открывающих эти файлы и пытаются использовать эти баги через специально сформированный файл для выполнения кода внедренного в файл. Это гораздо сложнее, успех мероприятия зависит от многих факторов, например вы должны использовать именно этот софт и его версию с найденной уязвимостью.
Драйвера лучше всего брать с сайта производителя материнской платы или с сайтов производителей оборудования, а не с каких-то левых сайтов.
Драйвера нужно брать под вашу версию винды.
Это практически исключит вариант, кривых драйверов и связанных с этим ошибок.
Останется только вариант - не исправно оборудование. Оборудование можно протестировать загрузившись с какой-нибудь диагностической сборки винды (например adminpe).
Такое тяжелое ПО лучше ставить из пакетов, а не из портов.
То что собираются зависимости - нормальное явление, у большинства портов/пакетов есть зависимости, а у таких тяжелых их много. Часто можно избавится от некоторых зависимостей, задав опции перед сборкой, но это, естественно, скажется на каком-то функционале ПО. То что зависимости собираются из исходников - ни чего удивительного, вы же ставите ПО из портов (т.е. из исходников), оно и все зависимости ставит таким же образом.
Из пакетов то же поставятся те же зависимости, только там это гораздо быстрее происходит, т.к. нет этапа сборки.
На счет ошибки - настоящую ошибку надо искать где-то выше, тут же только краткий итог операции.
Согласен с benipaz - десктопная винда однопользовательская в принципе. Да там можно "переключить" сеанс без завершения, но одновременно активным (т.е. пользователь может с ним работать) все равно может быть только один сеанс.
Для полноценной многопользовательской работы нужен Windows Server или ломать винду и лишаться лицензии. Владимир Коротенко,
Автовыкидфвание пользователя настраивается в политиках.
Дайте ссылку на политику? Буду только рад, если вы окажетесь правы :-)
Мой первый комментарий был о том, что понятия парадигм вполне себе актуальны и парадигмы есть в реальном коде. Но это не принципиальный вопрос. Парадигмы это не догма, их можно применять по отдельности или смешивать, там где ты считаешь это нужным. Выбор всегда остается за программистом.
Писать не используя парадигмы можно, но только очень простые приложения. Сейчас эти понятия уже настолько въелись в подкорку, что чтобы намеренно отказаться от них придется постоянно контролировать себя не скатится в парадигмы :)