Вкратце, при определении либы - `target_include_directories (mylib PUBLIC /path/to/include)`.
Если хедеры самой либе не нужны, а нужны только её пользователям - то вместо PUBLIC будет INTERFACE.
В основной программе (которая использует либу) конфигурим как `target_link_libraries (myprog PRIVATE mylib)`. И дальше #include в основной программе доступны хедеры, по пути, которые задала в своих свойствах либа.
Если под "упаковать" имеется в виду "куда-то поставить отдельным пакетом" - то, в общем-то, так же. Там можно задать путь, где лежат хедеры "прямо сейчас" (т.н. build_interface) - и они найдутся в случае add_subdirectory, и путь, где искать хедеры, если либа отдельным пакетом куда-то установлена (т.н. install_inerface). В обоих случаях сперва у вас будет add_subdirectory() (при сборке на месте), либо find_package() (при подключении к куда-то установленной либе), потом обязательно target_link_libraries на либу в основном проекте, уже по имени. А дальше сделает cmake. Либа найдена, пути известны, в свойства основного проекта они пропишутся и include заработает.
ой, в первом правиле option target "DNAT'. (оно так и станет, при загрузке. просто fw3 там внутри про себя ругнётся, что цель неправильна и потому станет дефолтным для redirect DNAT)
В целом подход верный, и в крайнем случае пойдёт.
Удалось создать по сути то же самое в luci.
config redirect
option target 'ACCEPT'
option proto 'tcp udp'
option src_dport '53'
option name 'Adult'
option src 'lan'
list src_mac 'AA:AA:AA:AA:AA:AA'
list src_mac 'BB:BB:BB:BB:BB:BB'
config redirect
option src 'lan'
option proto 'tcpudp'
option src_dport '53'
option target 'DNAT'
option name 'family-yandex-dns'
option dest 'lan'
option dest_port '65053'
option dest_ip '192.168.1.5'
Единственный момент - никаких ACCEPT в таблице nat. Везде редирект в порт 53 (что по сути ничего не меняет - клиент и так хотел в 53-й порт, ну мы и перенаправляем туда же).
Пока в рамках экспериментов получился такой "бесплатный" вариант. Взял синий 2-ваттный диод от проектора. Захостил его в указку вместе с фокусирующей линзой. Добавил драйвер с ebay, что питается от 12 вольт. И... прикрутил синей изолентой к экструдеру Printrbot Simple :). Сам драйвер - на клемму вентилятора обдува экструдера. Сам вентилятор - на клемму вентилятора на драйвере. Ну и модицифировал G-код (благо это легко автоматизировать) Осью z выставляется фокусировка. Нагрев и экструзию отключил. Команды управления вентилятором управляют лазером.
Сперва брал один произвольный периметр после slick3r, потом взял gcodetools для inkscape. В общем, вот так практически на коленке оно уже как-то заработало. Единственное - надо будет убавить мощность. Потому что ту же офисную бумагу он просто режет, как ножницы. А как попробовал получить толстую линию на куске гофрокартона так чуть не устроил пожар (лазер заставил картон тлеть. А обдувающий вентилятор ему помог).
А разница в цвете несущественна. Смотреть на процесс глазами никто не собирается :) Хотя, наверное, с видимым светом всё же комфортнее работать в плане настроек.
@Eddy_Em, а другие параметры сильно различаются? Для каждой длины волны я вижу, есть свои драйвера диодов, свои фокусирующие линзы. Вижу, у сравнительного мощного (10ватт кажется) ИК диода ширина кристалла 12мм - его удастся сфокусировать в точку? Или, может, для этого потребуется сложная оптическая система, которая выведет конечную стоимость гравёра на космическую орбиту?
А если возможности примерно одинаковы?
Вот вижу синий диод за 30 баксов, 2,4 ватта (пробег в проекторе около 100 часов)
Подобный IF стоит чуть-дороже (но новый).
Есть качественные различия, или можно просто по цене выбирать?
Это не совсем нетривиальная схема получается. Если на интерфейс ПК назначить сразу два ip-адреса (один от провайдера, второй - частный, для своей подсети) и настроить маршрутизацию/прокси между ними. А на ноуте назначить статический ip для частной сети.
Тут намного проще раздобыть какой-нибудь элементарный dir-300
Так прямо на порт и отправляйте!
Открывайте его прямо по имени (какое там? USB0? Или что-то похожее)? И в полученный дескриптор отправляйте последовательность байтов.
К SSD зануление применять не только не нужно, но и вредно!
Да, это "обычное блочное устройство", но у него есть и более глубокий уровень абстракции.
trim = "диск не используется". Значит, при записи/модификации можно смело использовать вейеринг ячеек (берём старое содержимое, модифицируем и пишем в _другую_ ячейку. А старое освобождаем (trim).
занулить = "диск используется" (всё равно, что записаны нули; на уровне абстракции диска это всё равно _информация_). Если занулить весь диск - значит, его ячейки уже не могут так просто использоваться для вейеринга, и скорость работы упадёт.
При чтении оба варианта (и trim и зануление) дадут одно и то же, однако подвергнутый trim-у диск свои освобождённые блоки будет читать гораздо шустрее (контроллер просто знает, что ячейки свободны - а потому даже обращаться к ним не будет; будет просто сыпать поток нулей в интерфейс)
ну просто делаем так на системе, где тулза есть:
strace -o /tmp/lsblk.dump lsblk -io KNAME,TYPE,SIZE,MODEL,MOUNTPOINT
grep 'open' /tmp/lsblk.dump
И там достаточно чётко видно логику работы lsblk:
берём папку /sys/block.
Перечисляем в ней сперва устройства sd*
Для каждого смотрим файл dev (например, /sys/block/sda/dev) - видим строчку, например, /sys/dev/block/8:0
заходим в папку по этому пути и смотрим там содержимое файлов:
size - размер диска
device/type - тип (0 - жёсткий диск)
device/model - модель
и т.д.
если дело не с целым диском, а с разделом - смотрятся /proc/swaps и /proc/mounts на предмет, не там ли где.
Только всё равно лучше в исходники глянуть, потому что он сложные случаи тоже обрабатывает. Например, у меня корректно смотрит через все абстрации LVM и видит логический том через VG и PV на конкретном физическом диске
Речь точно про sphinxql?
Просто там не поддерживаются никаких join!
(больше похоже на SphinxSE в mysql. Это совершенно другой механизм прокси SE обращается к демону searchd по старому Sphinx API, и к SphinxQL это не имеет никакого отношения!)
