← All posts tagged Linux

Добавил в старт роутера скриптик
#!/bin/sh

for table in filter nat mangle raw ; do
for chain in PREROUTING INPUT FORWARD OUTPUT POSTROUTING ; do
ip6tables -t $table -P $chain DROP
while ip6tables -t $table -D $chain 1 ; do true; done
done
done


Скорость интэрнета выросла с полумегабита до 60 мегабит, пинг упал на 40 мс (втрое).

Ну да, это не само по себе и не от хорошэй жызни — это какая-то хрень фигачить 10kpps запросов dhcpv6 solicit. В общий сегмент, в котором кажэтся большэ тысячи компов и дажэ администраторов я лично не знаю — общались минимум через двух посредников.
Но всё равно — полезный код, надо будет его во все роутеры вставить.

PS openwrt рулит.

Мне вот любопытно — а нафига Линус подписывает мелкие безсмысленные изменения в API? Вот в 4.9 — get_user_pages и ttm_bo_move_memcpy, которые менялись в 4.6 и 4.8. Изменения — откровенно шыло на мыло, век бы их не видеть, сделать новое имя и #define для старого — три строчки, документацыи разумеется никакой — как хипстерское говно со словом "рефакторинг" вообще можно пускать в какой-то серьёзный проект?!?

Ведро пинусов 4.7 (ну, на самом деле не знаю, с какого точно) при монтировании fat добавляет опцыю utf8. Дажэ если там до того прописан iocharset=. Ненависть.
Не то, чтобы добавить utf8=0 было так сложно. Но, блин, нафига они ломают работавшэе?

Сегодня в lkml случайно увидел, что кто-то патчит и поддержывает драйвер plip. Я, в принцыпе, рад, но чудны дела твои, софтиндустри.

PS Я как-то пытался лет почти 20 назад этим пользоваться. Оно было дажэ в общем юзабельно, только в общем обладало всеми недостатками SLIP при дальности передачи в два метра. Безсмысленно как-то.

запустил scilab после некоторого перерыва. После полуминуты тормозов и некоторой ругани libEGL (?) на DRI — вместо появления комстроки запустилось какое-то графическое гонево! Ну что за грибы, на полгода отвернуться нельзя, говнища какого-нибудь накидают!

Есть и хорошые новости: <<Сара Шарп (Sarah Sharp), разработчик стека USB 3.0 для ядра Linux, входящая в технический совет организации Linux Foundation, объявила об уходе из сообщества разработчиков ядра Linux.>>

И нет, я, разумеется, не про то, что кто-то не будет критиковать линуса за факи. Мне пофиг, линус, думаю, тожэ нормально к этому относится. Я про то, что код usb3 в линуксе — ужасен. Он в среднем ещё хужэ, чем всякие ad-hoc патчи на поддержку всяких засыпаний и прочего-нового вроде ehci на сильный линусовский код uhci/ohci.
Тот факт, что в ведре будет меньшэ появляться такого кода — это, конечно, плюс.

Debian, sudo...
Всё, сдаюсь, я ничего не понял. ВНЕЗАПНО на этой неделе прекратили работать команды вида "sudo ip ad ...", которые запускали скрипты, которые запускал openvpn, запущенный в свою очередь через service.

Такие жэ команды от меня работают. После sudo su — — работают. Разумеется, с полным путём — sudo /sbin/ip ad ... — работают.
sudoers следующий (опуская комментарии и пустые строчки):

Defaults env_reset
root ALL=(ALL) ALL
%staff ALL=(ALL) ALL
ilan ALL=NOPASSWD: /usr/sbin/visudo, /usr/bin/apt-get, /usr/bin/qemu-system-i386


Версия sudo:
Установлен: 1.8.10p3-1

/etc/sudo.conf — отсутствет.

А теперь, внимание добавление secure_path — решает проблему!!
Сейчас

Defaults env_reset, secure_path="/bin:/usr/bin:/sbin:/usr/sbin"

и всё, sudo ip ad ... — работает.
При том, что вроде дефолтный secure_path — ещё и /usr/local/bin:/usr/local/sbin включает (ну, по исходникам вроде так). При том, что вообще не должно быть никакой разницы между мной и root (exempt_group не установлена).

Вроде неделю назад (в предыдущую перезагрузка) оно работало. Что случилось, и почему так — непонятно.

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

Некоторая часть glx-приложэний прямо сразу после запуска падали с воплями... эээ.. Ну, точно не записал — но в общем — Unsupported GLX Request Opcode major: 155 (GLX), minor: 16 (private vendor request). А, да, от всякого dri я избавился путём установки дефолтной libGL вместо nvidia. Ну, DRI тожэ запретил в конфиге — но как-то оно не всегда запрещается.

Выяснение через tcpdump показало, что это был vendor 65536 — т.е. на самом деле не vendor, а glXSwapIntervalSGI из GLX_SGI_swap_control.

Ъ, у него возможные ошыбки — только BadValue. Ну да, glx у nvidia как обычно никто не тэстирует, и работает оно из рук вон плохо.
Пока что заменил в /usr/lib/nvidia/legacy-304xx/libglx.so.304.123 все строки GLX_SGI_swap_control на GLX_SGI_twap_control. И всё заработало.

(символ > вписан мною, чтобы отличать ввод от вывода)
0_ilan@azor /tmp%bc -l
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
obase=2
scale=100
18.9
10010.1110
18.9010010.1110011
18.9000000000000000000010010.11100110011001100110011001100110011001100110011001100110011001\
10011
189/1001.111000111101011100001010001111010111000010100011110101110000101000\
11110101110000101000111101011100001010001111010111000010100011110101\
11000010100011110101110000101000111101011100001010001111010111000010\
10001111010111000010100011110101110000101000111101011100001010001111\
010111000010100011110101110000101000111101011100001010001111010

Вдогонку к #2752250: он ещё и распух в 7 раз. Тот, что стоит у меня installed-size 834k, новый — 6 метров.
Сказочные дегенераты его в последнее время делают.

Надо перелезать на hotplug2.

после установки LPT-порта стал виснуть SANE. Да-да, разумеется, как раз тогда, когда основной комп со сканером выгорел нафиг (на USB GND упало 220В), и сканер воткнули в меня (а использовали с соседнего компа через SaneTwain).
В логах — молчок. Попытки сконнэктиться — ничего не выдают (ну, соединение, установление протокола, поиск сканеров зависает). Попытки подключиться strace к работающему — сразу начинает работать как ожыдалось, т.е. всё пролетает.
В общем, запустил saned через strace сразу — висит на попытку PP_CLAIM на /dev/partport0. Ну, естественно, кто ж ему даст, там ужэ openocd висит. Попытки поискать слово parport в конфигах ни к чему не привели, потому я решыл, что наконец надо взять и возглавить этот бардак. Тем более, что прикол с тем, что локальный xscanimage показывал по два варианта каждого девайса — через локальный net и через порты — тожэ был. Да и появлялялась кроме сканера всякая левая фигня — например, мой TV-тюнер.
В общем, в итоге, грустно посмотрев на конфиг SANE — пришёл к такому варианту:
Всё, что там было — выкинул в /etc/sane.d/notused .
Единственный оставленный дефолтному xscanimage backend — net, т.е. создал в /etc/sane.d/dll.d/ файлик с незатейливым именем net и таким жэ содержанием (можно было это слово в /etc/sane.d/dll.conf прописать — но мне показалось правильней чтобы dll.conf был пустым и никто его не трогал при апгрэйдах sane, а все примочки приходили через /etc/dll.d)
Для работы самого saned создал папочку /etc/sane.d/saned ,
в /etc/default/saned добавил строчки:

SANE_CONFIG_DIR=/etc/sane.d/saned/
export SANE_CONFIG_DIR

(минут наверное 15 потратил, поскольку забыл поначалу про export. Старость не радость.)
В этой папочке содержатся: файлик /etc/sane.d/saned/dll.d/iscan со словом epkowa — включает (подгружает) бэкэнд epkowa для моего epson perfection v100
/etc/sane.d/saned/epkowa.conf — очень дефолтная конфигурацыя этого бэкэнда. Надо оттуда, кстати, упоминание scsi убрать — быстрее будет.
/etc/sane.d/saned/saned.conf — разрешэния для локальной сетки.

В общем, в итоге всё скорее работает. Правда, тот факт, что к saned можэт подключаться только один клиент — несколько возмущает.

Некоторое время назад обнаружыл, что glxgears, запущенные через честный nvidia glx — т.е. на удалённом хосте. Или на локальном, но через tcp/ip, а не unix domain и с export __GL_FORCE_INDIRECT=1 — так вот, запущенные безо всякого dri и shm — стоят на месте и вообще от них практически ничего не добьёшся. Притом пишут один раз какое-то невменяемо большое число fps. А вся система как-то ощутимо тормозит.

Сегодня разобрался детальней.
Во-первых, они -не тормоз, а медленный газ- не стоят на месте, а весьма медленно крутятся. Притом только новые, у которых видимо угол поворота вычисляется в зависимости от скорости в fps, чтобы они не крутились слишком быстро — у старых всё лучшэ с этим.
Во-вторых, вставленная отладочная печать обнаружыла следующую вещь: эта хрень пишэт в какие-то буфера (ну, в буфер приёма/передачи иксов, очевидно) сразу пачку команд на отрисовку фрэйма — пока не заткнётся. Около 15 тысяч фрэймов помещается.
Эти фрэймы рисуются со скоростью, определённой synctovblank. Т.е. около 60 fps. То есть минут 5 по-хорошэму.
При этом почему-то через несколько секунд проскакивает ещё один фрэйм, потому glxgears получает возможность написать свою дикую скорость да ещё и скорректировать скорость вращения.
И потом всё, на несколько минут оно затыкается.

Очевидный вариант решэния — XSync() или хотя бы XFlush() после каждого фрэйма. В общем, XFlush() почему-то работает дажэ лучшэ — в смысле — с ним — скорость 60 fps, а с XSync() — 30. Но это работает.
Ещё вариант — через nvidia-settings поставить nvidia-settings -a SyncToVBlank=0, тогда будет выдавать свои максимальные fps (у меня около 3000 при варианте через ssh на localhost), и особо не затыкаться, поскольку некогда.
Кстати, скорость через tcp/ip причти одинакова независимо от того, замаплено окно или нет — отличается вроде на 10%. Притом оно на 20% медленнее, чем через direct rendering если окно замаплено и в 3 по-моему раз медленнее если окно незамаплено.
Но вообще — надо с этим что-то делать, поскольку opengl-приложэния привыкли, что если SwapBuffers() прошло, то всё, пользователь ужэ видит на экране картинку — а тут такая херня творится.

xfs отказалась работать со стэктрэйсами. Притом, судя по всему, сначала проблема возникла когда оно не смогло что-то прочитать с одного диска (lvm snapshot переполнился, фиг с ним, оно несколько раз в день для создания бэкапа деляется) — а потом все xfs диски повисли нафиг.
Ребут помог.
Подумываю о виртуализацыи.