Приветствую.

Наверное, многим известна ситуация с энергосбережением на Intel-платформах в Linux. Она заключается в том, что всё больше компонентов перетаскивается с материнской платы на процессор, и для хорошего энергосбережения всё важнее становится разрешать этим компонентам спать.

(Об этом пишет Matthew Garrett, например, вот здесь.)

В частности, на Haswell и выше есть вполне задокументированная зависимость между разрешением основного дисплея и максимальным Package C-state, в которое кристалл сможет упасть. Для моего Thinkpad T540p и штатного разрешения 2880x1620 это всего лишь PC3 (из возможных семи). Следовательно, энергопотребление этого ноута при штатном разрешении никогда не опускается ниже 12W, но если сменить разрешение на 1024x768 — оно сразу же падает до 7-8W.

Однако, есть такая весёлая штука, как PSR (Panel Self-Refresh). Насколько я понял, это «умные» дисплеи, которые умеют обновлять кадр по частям и самостоятельно его перерисовывать. В той же доке на Haswell написано, что в системах с PSR чип сможет падать в PC7 вне зависимости от разрешения, но для этого нужна поддержка в видеоядре и в самой матрице. Судя по логам, второй у меня нет.

Отсюда вопрос: нельзя ли где-либо добыть хотя бы электрически совместимую с T540p матрицу с поддержкой PSR?

P. S.: если у кого-то есть T550 или T560, прошу загрузиться с параметрами ядра i915.enable_psr=1 drm.debug=0xe и скинуть лог ядра (dmesg) и/или содержимое файла /sys/kernel/debug/dri/0/i915_edp_psr_status.

Приветствую.

Исходная задача: нужно в неинтерактивном режиме запустить ssh-keygen -y -f $privkey и скормить ему парольную фразу, причём сделать это максимально секьюрно. С stdin он её читать не хочет.

Переформулировка задачи: я решил запускать ssh-keygen, передавая ему в качестве SSH_ASKPASS путь к вспомогательной программе, которая, запустившись, как-то получит у меня парольную фразу и отдаст её ssh-keygen'у в stdout. Вопрос: как?

• Тупо скормить в stdin и надеяться, что запущенный псевдо-askpass унаследует файловый дескриптор от ssh-keygen'а — ненадёжно, в будущей версии openssh могут решить закрывать все fd на всякий случай.
• Создавать named pipe, System V SHM, ... — несекьюрно, можно успеть подключиться раньше и вычитать оттуда всё что нужно.
• Что ещё?

Clarification. В итоге я всё-таки заставил ssh-keygen читать парольную фразу из stdin без применения костылей с подложным SSH_ASKPASS. Для этого нужно убрать переменную DISPLAY= и завернуть процесс в setsid, чтобы отобрать доступ к /dev/tty:

( unset DISPLAY; exec setsid -w ssh-keygen -y -f "$privkey_file" < "$passphrase_file" )

Приветствую.

Контекст — обычные студенческие физлабы, но хотелось бы сделать максимально «правильно».

Итак, имеется несколько экспериментальных результатов, представляющих собой арифметические выражения от показаний (нескольких) приборов, и соответствующие им «погрешности». Я не знаю, как это правильно называется с точки зрения статистики, но последние были посчитаны исходя из величины деления шкалы и классов точности приборов по известным правилам вида «относительная погрешность произведения ...». В каждом случае эти «погрешности» получились существенно разными, сами результаты тоже несколько отличаются.

Вопрос: как усреднить результаты и посчитать «погрешность» среднего (видимо, это называется стандартное отклонение...) с учётом вышесказанного? На пальцах — я хочу что-то вроде взвешенного среднего, и какой-то способ оценить погрешность того, что получится.

Дисклеймер: курсов матстата, теории вероятности, теории эксперимента и тому подобных у нас не было. Буду благодарен, если кто-то ответит более развёрнуто, чем «читать вон туда».

Недавно вкатил себе zsh. С уберсложной подсистемой автодополнения ещё почти не разбирался. И вот есть вопрос.

Дано: практически дефолтный (с точки зрения настроек автодополнения) zsh. Задача: поиметь возможность дополнения из истории команд.

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

bindkey  "^[[A" history-beginning-search-backward
bindkey  "^[[B" history-beginning-search-forward

Вопрос: как сделать автодополнение из префикса по истории? Так, чтобы по нажатию, скажем, Ctrl+Tab 1) дополнялись целые строчки из истории, соответствующие введённому префиксу, и 2) из этих строчек можно было составить меню (menu select включено).

https://github.com/bus1

Просто из коммит-лога. Код модуля уже неделю не трогали, везде последние коммиты — это какие-то мелкие исправления, комментарии и тесты.

Для Ъ: bus1 — это то, что они пилят вместо kdbus. Просто IPC в ядре, без какого-то конкретного протокола (формата сериализации etc). Видимо, с тем расчётом, чтобы поверх этого уже в юзерспейсе натянуть dbus. А ещё там в соседних репозиториях полнофункциональный игрушечный пример юзерспейса на этом bus1. Отдельный игрушечный загрузчик, инит, аналог udev и всё такое. Вот это вообще круто, откуда у них время и силы?..

А что по этому поводу думает ЛОР? Я ведь уверен, что много чего.

enum Edge<T> {
	Edge(Option<T>),
	Nothing
}

impl<T> fmt::Display for Edge<T> {
	fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
		write!(f, "{}", match self {
			&Edge::Edge(_)        => "E",
			&Edge::Nothing        => "-",
		})
	}
}

impl<T: fmt::Display> fmt::Display for Edge<T> {
	fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
		write!(f, "{}({})", match self {
			&Edge::Edge(_)        => "E",
			&Edge::VirtualEdge(_) => "e",
			&Edge::Nothing        => "-",
		}, match self {
			&Edge::Edge(Some(v))        => v,
			&Edge::VirtualEdge(Some(v)) => v,
			_                           => "-"
		})
	}
}

Так нельзя, потому что в расте нет специализации. А как в таких случаях надо писать?

Замысел состоит в том, что второй impl основной, а первый — fallback на тот случай, если Edge инстанцировали от чего-то, что нельзя распечатать.

struct Foo;

impl Foo {
    fn get(&self) -> usize {
        42
    }
    
    fn set(&mut self, b: usize) {
    }
}

fn main() {
    let mut f = Foo;
    
    f.set(f.get());
}

results in

<anon>:15:11: 15:12 error: cannot borrow `f` as immutable because it is also borrowed as mutable [E0502]
<anon>:15     f.set(f.get());
                    ^
<anon>:15:5: 15:6 note: previous borrow of `f` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `f` until the borrow ends
<anon>:15     f.set(f.get());
              ^
<anon>:15:19: 15:19 note: previous borrow ends here
<anon>:15     f.set(f.get());
                           ^
error: aborting due to previous error
playpen: application terminated with error code 101

Почему? Здесь всё верно, иммутабельное заимствование f при вызове get() кончается до вызова set().

навеяно недавней новостью про gzip

Собственно, вопрос: какой формат архива и какая его реализация сейчас претендует на звание Современного Универсального Архиватора™? Например, если нас совершенно не волнует обратная совместимость — то есть ли такой архиватор, который всегда сжимает лучше gzip и работает быстрее gzip (без учёта многопоточности)?

Почему случился WВИМ? Поиск по сайту ничего не дал.

Приветствую.

Как известно, стандартная модель прав POSIX работает только в том случае, когда мы хотим защитить файлы от процессов, работающих с другими учётными данными.

А что делать, если мы хотим защититься «от себя», т. е. от недоверенных программ, запущенных с теми же user/group?

Например, у меня в хомяке лежат какие-то приватные ключи. И я хочу, чтобы к ним не имел доступа никакой процесс, в т. ч. запущенный от моего имени, пока я явно не разрешу этот доступ конкретному PID'у (и, например, всем его потомкам).

В идеале я бы хотел некую команду (требующую права рута, например), которая запускала бы специальный шелл — от моего имени, но имеющий доступ к этим файлам. А остальные процессы пусть получают -EACCES.

Возможно ли такое? SELinux?

Clarification. На самом деле SELinux — это последний вариант, потому что в арче придётся полсистемы пересобрать с ним, включая ядро. Тем, кто компетентен в SELinux, я лучше задам конкретный вопрос: можно ли его настроить так, чтобы не приходилось переписывать политику для каждого нового установленного приложения? Иными словами, в режиме «всем всё можно, кроме вот этой директории — в неё нельзя вообще никому, кроме помеченных в рантайме PID'ов».

Сабж. Есть C99 (совместимость с компиляторами кроме gcc и clang не нужна, совместимость с libc кроме glibc — тоже); есть самописные мьютексы (mutex_t, mutex_lock(mutex_t *), mutex_unlock(mutex_t *)).

Хочется сделать автоматическое освобождение захваченного мьютекса при выходе из захватившей его функции (типа std::lock_guard в плюсах). Очевидное решение — локальная переменная с адресом мьютекса и __attribute__((cleanup(...))), но хочется сделать красивее, без лишних локальных переменных: ведь адрес мьютекса известен ещё на этапе компиляции.

Возможно?

Приветствую.

Собственно, мне нужно заиметь вспомогательный поток, при этом не пользуясь pthread.

Заиметь-то я его заимел с помощью clone() (без CLONE_PARENT), поток завершается с помощью syscall(__NR_exit, 0) — а как теперь его подождать в основном потоке? waitpid(tid, NULL, __WALL) говорит -ECHILD.

UPD: окей, ман говорит, что так делать нельзя:

              A new thread created with CLONE_THREAD has the same parent
              process as the caller of clone() (i.e., like CLONE_PARENT), so
              that calls to getppid(2) return the same value for all of the
              threads in a thread group.  When a CLONE_THREAD thread
              terminates, the thread that created it using clone() is not
              sent a SIGCHLD (or other termination) signal; nor can the
              status of such a thread be obtained using wait(2).  (The
              thread is said to be detached.)

А как тогда?

Доброго седьмого дня недели, бояре. Собственно, вопрос навеян этим тредом: как обстоит дело со сменой WLAN-карточки у ThinkPad T540p?

Сейчас у меня 0x8086:0x08b2, т. е. «Intel Corporation Wireless-N 7260». Хочу что-нибудь с 802.11ac и как можно более future-proof. В то же время совокупляться с говноблобами, которые не умеют в cfg80211, нет никакого желания. Что посоветуете?

Разыскивается аудиоплеер, который:

• имеет неубогий интерфейс
• умеет вести базу данных коллекции (хотя это необязательно)
• умеет группировать треки по albumartist'у (в отличие от Rhythmbox, например)
• умеет читать и показывать тексты песен из тегов самих файлов (а не фетчить откуда попало)

Последнее требование самое важное. Даже офигенный Ex Falso/Quod Libet (казалось бы, кому, если не разработчику mutagen'а, знать про теги всё?) этого не умеет.

UPD: теперь умеет. Подходящий плеер найден путём патчинга неподходящего.

Сабж. Есть ли в сейлфише способ управлять текстовым курсором жестами? Например, было бы удобно, если бы горизонтальное перемещение пальца по экранной клавиатуре вызывало бы соответствующие перемещения курсора. (Чтобы было понятно, о чём я — в iOS это достигается твиком SwipeSelection.)

Сабж. Допустим, я хочу вести бложик с заметочками и каким-то там about-разделом. Также хотелось бы, чтобы:

• не было монструозности (один формат, статический реген, никаких встроенных языков программирования, никаких встроенных стилей)
• маркдаун (желательно pandoc markdown)
• один пост — один файл
• естественная структура (/a/b/c/file.md ⇒ рубрики a⇒b⇒c, запись file)
• теги симлинками, дата модификации из mtime или из Git

В общем, что-нибудь такое, во что можно было бы запихнуть уже существующий Git-репозиторий с отсортированными заметочками и получить читаемый и навигабельный результат, размеченный семантическими тегами из HTML5. И уже только потом тратить время на украшательства.

Есть подобный софт в мире?

Сижу, долблюсь в файрволл опенвртшный. Есть админская зона, есть пользовательская, есть гостевая. Ещё есть VPN'ный интерфейс, который тоже в отдельной зоне (точнее, сразу в двух, по подсетям).

Разрешил форвардинг из VPN'а в нормальную пользовательскую зону, дабы дать человеку remote access к его машине. Обратно, соответственно, по умолчанию, т. е. reject. Проверил, что форвардинг ESTABLISHED/RELATED тоже разрешён. Пингую девайс из пользовательской зоны — хрен. И счётчик реджектов растёт.

Удостоверился в том, что conntrack для ICMP вообще существует в природе. Офигел, почесал репу. Полез на опенвртшное вики. А там —

By default, the firewall will disable connection tracking

Surprise, motherfucker. И зачем так делать, да ещё и по дефолту? И вместе с тем форвардинг между зонами по дефолту однонаправленный, т. е. по сути априори неработающий. Принцип наименьшей неожиданности нервно курит в сторонке.

Не так давно я перевёл свою домашнюю файлопомойку (1x1TB, 2x500GB) на zfs. Дисков мало, все они разные, поэтому никакого рейда — просто критические данные лежат на подтоме, для которого включено дублирование данных.

Сначала всё было хорошо. Потом ввод-вывод стал дико тормозить. А потом я наткнулся на статью, в которой красочно рассказано, как расп-дорашивает zfs от случайных перезаписей, если забить её данными хотя бы наполовину. А у меня из 1.8T занято 1.5T, и, видимо, так дальше жить нельзя.

Отсюда три вопроса:

1. что делать (помимо того, что «вдоль» и «докупать больше дисков»)?
2. как будут обстоять дела в подобных ситуациях у btrfs?
3. какие ещё есть ФС из «комбайнов» со снапшотами, подтомами, компрессией и так далее?

Update #1. Нагрузка на ФС — торренты и sqlite-овая БД размером в один гигабайт. Тормоза наблюдаются с последней.

Update #2. После того, как я сделал synchronous = 0; для sqlite-овой БД, всё стало сильно лучше. Вопрос «какого хрена?» всё ещё в силе, т. к. intent log имеется.

$subj. (После)завтра. Я, конечно, вовремя, но всё же.

Вдруг кто-то с ЛОРа туда едет?

Вечер добрый.

Имеется ряд идиотских вопросов по настройке tc/QoS/шейпинга/etc. на роутере с OpenWRT. А именно:

• Есть ethernet-интерфейс (свитч), который разделён на несколько VLAN-ов, часть которых объединена в мост с WLAN-интерфейсом. На что из этого нужно вешать qdisc-и?

  По умолчанию на wlan0 висит mq, на eth0 — fq_codel, на остальных — ничего (noqueue):

  # ip link
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
      link/ether 14:cc:20:62:c1:ab brd ff:ff:ff:ff:ff:ff
  5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
      link/ether 14:cc:20:62:c1:ab brd ff:ff:ff:ff:ff:ff
  6: eth0.3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default 
      link/ether 14:cc:20:62:c1:ab brd ff:ff:ff:ff:ff:ff
  7: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
      link/ether 14:cc:20:62:c1:aa brd ff:ff:ff:ff:ff:ff
  8: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP mode DEFAULT group default qlen 1000
      link/ether 14:cc:20:62:c1:ac brd ff:ff:ff:ff:ff:ff
  170: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100
      link/none
  
  # tc qdisc
  qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
  qdisc mq 0: dev wlan0 root 
  qdisc fq_codel 0: dev wlan0 parent :1 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
  qdisc fq_codel 0: dev wlan0 parent :2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
  qdisc fq_codel 0: dev wlan0 parent :3 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
  qdisc fq_codel 0: dev wlan0 parent :4 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn 
  qdisc fq_codel 0: dev tun0 root refcnt 2 limit 1024p flows 1024 quantum 300 target 5.0ms interval 100.0ms ecn
  

• Насколько я понял из кучи разных мануалов, шейпить ingress нельзя. Разные вики (вроде арчвики) предлагают использовать для этих целей промежуточный интерфейс и наборчик костылей для того, чтобы подружить классификацию с маскарадингом.

  Но у меня роутер, и вопрос звучит так: почему вместо плясок с перенаправлением ingress'а WAN-интерфейса нельзя повесить шейпинг на egress LAN-интерфейса?

• Вообще, в какую сторону следует конфигурить tc, если особых проблем с задержками не наблюдается, а нужно исключительно заставить гостевую WLAN-сеть не мешать основной?

  Какие qdisc стоит использовать? Как классифицировать трафик?

  Другими словами, нужно ли делать что-то сверх банального «на корень HTB, на листья fq_codel, трафик с этих IP в один класс, с этих IP в другой», если я ещё не знаю точно, чего я хочу?

Я сейчас читаю LARTC и, честно говоря, немного охреневаю от количества вещей, которые требуется одновременно держать в голове.

Алсо, devl547. Я где-то видел тебя рассуждающим про traffic control — может, тебе есть, что сказать?