Собсно столкнулся с немного странной проблемой при использовании термкапа: при попытке использования каких либо команд тот падает лицом в асфальт, выдавая ошибку сегментации. Поначалу грешил на свой код, но в результате тестов, оказалось, что сегфолтит даже простейший мейник вида:

int main(void)
{
	struct termios	term, cur_term;
	int width;

	tcgetattr(0, &term);
	cur_term = term;
	cur_term.c_lflag &= (unsigned long)~(ICANON | ECHO | ECHONL);
	tcsetattr(0, TCSANOW, &cur_term);
	width = tgetnum("co");
	printf("%d\n", width);
	tcsetattr(0, TCSANOW, &term);
}

Тот же код вполне адекватно работает под убунтой и макосью. ЧЯДНТ?

Столкнулся сразу с несколькими вроде не критичными, но раздражающими проблемами связанными с управлением подстветкой. Подозреваю, что причина у данных проблем одна и она счас сидит пишет это сообщение, потому опишу всё в одной теме.

Действие происходит на Thinkpad X201 с Arch Linux, в GRUB прописано acpi_backlight=vendor.

1. При подключении/отключении кабеля питания, яркость каждый раз сбрасывается на 65%. Где это может устанавливаться? В udev правил не настроено, acpid отключён. В journalctl ничего, udevadm monitor показывает только собственно записи о подключении кабеля, типа таких:

KERNEL[1269.498720] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV  [1269.500291] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
KERNEL[1269.986003] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/PNP0C09:00/ACPI0003:00/power_supply/AC (power_supply)
UDEV  [1269.988092] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/PNP0C09:00/ACPI0003:00/power_supply/AC (power_supply)

2. При этом заметил, что udev-правила не подтягиваются сразу при включении системы. То есть если в первые минуты работы ноутбука, к нему подключить питание, экран всё равно засетится в 65%. И только через какое-то время будет сбрасываться в 40%. В journalctl -xef увидел следующее касательно systemd-udevd:

Jan 11 13:19:35 miminote systemd-udevd[311]: AC: Worker [313] processing SEQNUM=2304 is taking a long time
Jan 11 13:19:35 miminote systemd-udevd[313]: Spawned process '/usr/bin/xbacklight -set 40' [352] is taking longer than 59s to complete

Jan 11 13:21:35 miminote systemd-udevd[313]: Spawned process '/usr/bin/xbacklight -set 40' [352] timed out after 2min 59s, killing
Jan 11 13:21:35 miminote systemd-udevd[311]: AC: Worker [313] processing SEQNUM=2304 killed
Jan 11 13:21:35 miminote systemd-udevd[311]: Worker [313] terminated by signal 9 (KILL)
Jan 11 13:21:35 miminote systemd-udevd[311]: AC: Worker [313] failed

3. Нажатие кнопок яркости (Fn + Home/End) генерируют сразу 2 нажатия XF86MonBrightnessUp и XF86MonBrightnessDown соответственно. Если запустить acpid и посмотреть acpi_listen, это будет выглядеть вот так примерно:

video/brightnessup BRTUP 00000086 00000000 K
video/brightnessup BRTUP 00000086 00000000

video/brightnessdown BRTDN 00000087 00000000 K
video/brightnessdown BRTDN 00000087 00000000

Надеюсь на помощь ЛОРа

Есть 2 процесса, в одном из которых хранится некий список структур с данными, а второй должен получать эти данные от первого и выводить в терминал. После раскуривания мануалов по работе с сокетами для реализации этого всего возникло несколько вопросов, ответ на которые хотелось бы услышать от живых людей.
Что есть более unix-way решением: формировать вывод на стороне первого процесса и передавать в сокет в виде строк, чтобы второму оставалось только прочитать из сокета и вывести то, что получил, либо же передавать сокетом структуры в бинарном виде, а на стороне второго процесса их обрабатывать и потом уже выводить? Либо же оба решения применимы и не будут в итоге торчать костылём? А также, возможно есть какие-то преимущества в датаграммном или потоковом сокетах для данной задачи, либо же оба одинаково эффективно можно использовать, при учёте, что вся передача будет на одном хосте?
Данные, если что, первый процесс должен пересылать после получения команды от второго. Вот.
Буду благодарен за советы касательно этого вопроса.

Доброго здоровья всем Есть цель сделать скрипт для автологина при входе на коммутаторы через telnet. Изначально думал сделать банально, чтобы скрипт читал вывод до слов username и password, а всё остальное делать ручками. Однако до моих ушей дошла идея, что можно в этом деле еще заюзать snmp, дабы он перед подключением получал версию прошивки свича и в зависимости от этого производил некие дополнительные действия (вход в режим конфигурации и ввод того или иного логина на свичах без радиуса). Сел курить подробно статьи о работе snmp, однако пока что к сожалению удалось понять только основы как оно работает, без понимания синтаксиса конкретных команд, не говоря уже о том как это заюзать в питоне. Очень рассчитываю на Вашу помощь в этом вопросе, возможно кто-то подскажет где можно более детально получить информацию на этот счёт, т.к. гуглинг пока что дал в основном основную информацию о работе протокола.

Еще когда только узнал о Raspberry Pi пару лет назад, появилось желание приобрести и себе подобный девайс, но всё как-то откладывалось за наличием более важных дел. И вот я таки собрался со своей хотелкой и твёрдо решил обзавестись одноплатником. Однако изучив вопрос подробнее, понял, что за это время выбор стал гораздо богаче и с малинкой всё теперь не так однозначно, ведь есть множество плат, которые либо дешевле, либо имеют лучшие характеристики при той же цене.
Устройство в планах будет применяться в самых разнообразных целях, в зависимости от идей, пришедших ко мне в голову, однако заданием по умолчанию должна быть поддержка небольшого домашнего сервера. Выбирать стал исходя из общих характеристик аппаратов + наличии на них полноценных дистрибутивов линукса.
В итоге остановился на трёх вариантах:

• ODROID-C1+
• Orange Pi Mini 2
• Orange Pi PC

Все три компьютера имеют примерно одинаковые характеристики, но при этом довольно разнящиеся цены. Сам я довольно неопытен в этом вопросе, потому несмотря на недельное изучение всех аспектов сабжей, всё же теряюсь с ответом (собственно, потому уж и решился попросить помощи у общественности), на каком же из них стоит остановиться? Взять что-то более дорогое и производительное, но с вероятностью получить лишних проблем из-за сырости проектов? Или же не стоит любить себе мозг и взять Малину 2Б с большим комьюнити?.. Но процессор отталкивает...
Очень надеюсь на Вашу помощь.