И так у меня была репа фрибсд, скаченная 3 года назад в виде одной ветки main (да, там тоже не master, а ещё про этот --single-branch я забыл), и захотел я подгрузить к ней актуальные изменения, а так же релизные ветки 13.5 и 14.3. С первым всё получилось (git pull), скачал он объектов примерно на полгига и всё обновил.

Потом я сделал git checkout releng/13.5 - пишет нет ветки. Сделал git pull origin releng/13.5 - он долго-долго качал ещё гигабайт объектов (почему? почти всё уже скачано было раньше должно бы быть), потом начал какой-то дурацкий мерж, выдал кучу ошибок и упал. Ветка releng/13.5 нигде не появилась, ни в refs/heads и в refs/remotes/origin. Вобщем, репа оказалась в каком-то забагованном состоянии, но git reset --hard починил её, а потом ещё пришлось вручную rm всякий мусор от упавшего мержа. Хорошо, выяснил что pull не для этого, сделал git fetch origin releng/13.5 - он ничего не делает как будто всё и так норм. Сделал git fetch origin releng/14.3 - он скачал ветку (на этот раз быстро и малым объёмом), но ни в каких списках она опять не появилась.

Вобщем, оказалось что надо лезть в .git/config и в конфиге [remote "origin"] заменить main на звёздочки, иначе он делает вид что остальных веток не существует, даже если я напрямую его инструктирую их скачивать. Хорошо хоть качать заново не пришлось. Если что, после правки конфига надо было ввести такие команды:

git fetch origin releng/13.5   # прописать ветку в remotes
git checkout -b releng/13.5 origin/releng/13.5   # склонировать её в локальные
git fetch origin releng/14.3
git checkout -b releng/14.3 origin/releng/14.3

Ладно, отказ создавать ветки можно понять (в конфиге запрещены), но почему он делает это молча и изображая что всё успешно получилось? Мог бы ошибку написать что конфиг не разрешает эти ветки трогать, например, я бы сразу понял в чём дело и исправил. а так же плохо с его стороны было качать кучу объектов, которые, в соответствии с конфигом, ему нужны быть не могут - опять же надо было сразу выдать ошибку и ничего не делать. И до сих пор непонятно - если я хочу ограничить работу, но не одной веткой а тремя - это возможно?

Уже спрашивал, может с тех пор новая информация будет.

Когда вылетает pppd и исчезает интерфейс ppp0 - файрфокс отменяет все имеющиеся сетевые запросы от себя. При этом если грузилась какая-то новая вкладка, то загрузка просто прерывается без каких-либо оповещений, во вкладке остаётся пустое окно, зафейленной она не считается и ф5 в ней не работает (хорошо хоть можно навести фокус на урл и нажать энтер). Как это дефективное поведение отключить (всмысле, отключить вообще любые попытки реагировать на состояния сетевых интерфейсов)? Есть штатный способ? Или может быть костыльный (но без виртуалок итд подобного)?

На всякий случай сразу уточню: все коннекты идут через локальное прокси, соответственно никакие проблемы с сетевыми интерфейсами на возможность фф общаться с этим прокси физически не влияют. То есть это исключительно его вредительское желание принудительно оборвать работающие коннекты.

Есть, предположительно, огромный массив (или что-то более структурированное, например btree), из однотипных элементов (но могущих быть разного размера в байтах). У этого списка надо организовать криптографическую проверку целостности с помощью хэша, но с дополнительным условием: при вставке/удалении/замене элемента откуда-то из середины надо чтобы не требовалось заново пробегать по каждому из элементов и пересчитывать его.

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

Придумал вроде бы несложное решение, но хочется посоветоваться с кем-нить на предмет его возможных проблем. То есть, не будет ли это решение понижать криптографическую надёжность хэша в каком-нить аспекте (в первую очередь - давать возможность подменить исходные данные при сохранении того же хэша).

Предлагаемая схема. Берём некий уже готовый традиционный криптохэш, считающийся надёжным по условию извне задачи. Этим хэшом хэшируем каждый элемент списка отдельно. Итоговый хэш списка считаем как степенной ряд с хэшами элементов в качестве коэфициентов:

hash(item[0..N-1]) = hash(item[0]) + hash(item[1]) * k + hash(item[2]) * pow(k,2) + ... + hash(item[N-1]) * pow(k,N-1)

где k - некое большое простое число, разрядностью равной или чуть меньше разрядности базовой хэш-функции, N - количество элементов списка, item[] - массив элементов, pow() - функция возведения в степень большой разрядности, hash() - базовая хэш-функция. Вся арифметика считается по модулю разрядности хэша, разумеется.

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

И ещё вопрос: если базовая хэш-функция уже обладает какими-то недостатками, но ещё не проявляющимися на практике (т.е. отдалённо-теоретическими), может ли её использование в указанной выше схеме обострить значимость этих недостатков и сделать их практически эксплуатируемыми?

И ещё вопрос: а если k имеет заметно меньшую разрядность чем базовая хэш-функция, это чему-то навредит?

При запуске pm-hibernate иногда (кажется шансы растут с увеличением аптайма) в консоль начинают очень быстро флудиться ошибки вида

write-error on swap-device (какие-то цифры, меняются)

Кажется этого не происходило на старом диске где свап-раздел был меньше (но точно не помню какой). Сейчас так

Filename				Type		Size		Used	Priority
/dev/sdb2                               partition	16777212	0	-2
/dev/zram0                              partition	7812496		0	10

soomrack ?

Настраиваю 16000 (через snd_pcm_hw_params_set_rate_near), при этом и с микрофона идёт примерно 15980 и на динамики оно принимает примерно столько же. Пока что решил тупо дропом невлезающих сэмплов (а для стрима с микрофона дублирую примерно 20 штук в секунду равномерно размазанных по секунде, да я догадываюсь что любители чистого звука такой способ ресэмплинга осудят, но не суть).

Так вот, вопрос такой, это нормальная ситуация или надо считать дефектом звуковой карты или какими-то неправильными настройками?

И если нормальная, то как это обычно решается, неужели ресэмплят всё подряд? Или может номинальное 16000 на самом деле должно быть 15980 и его просто округлили?

Не знаю может тема для development, перенесите если надо.

Подозреваю, что числа эти попадают в sysfs прямиком из контроллера батареи без каких-то обработок ядром, но всё же.

Обычно я стараюсь не опускать заряд меньше 20% (делаю suspend и иду/еду заряжать), но тут над было, он опустился до 7.1% и там завис. Сидел на нём больше полчаса (притом что батареи всего на полтора-два хватает, она старая, но эта оценка экстраполяцией поведения при 20%+ на разряженные состояния), он так дальше вниз и не сдвинулся. Когда поставил на зарядку, он 35 минут висел на этой точке, потом начало расти, за следующие 140 минут дошёл до 86%.

У меня есть две теории:

1) контроллер неверно оценил убитость аккума и на самом деле его 100% заряд больше чем он думает

2) на 7% начались какие-то крайне вредные процессы глубокого разряда и оно тратилось в какую-то недопустимую сторону (но я в этом не разбираюсь)

Что-то из этого правильно или ещё что?

energy_full = 12440000 (ёмкость 100% аккума в каких-то условных единицах)

energy_full_design = 28510000 (я так понимаю это ёмкость аккума когда он был новый)

Почему такое может быть?

mount | grep home
lsof | grep home

пустые.

mv /mnt /mnt2 работает норм.

Подозреваю что туда что-то смонтировано в каком-нить другом mount namespace, как их всех посмотреть?

Ядро 3.10 от centos7.

Я могу частично согласиться с тем, что ответы «докер не нужен» в темах «как настроить докер» не особо полезны, но это тут причём?

crontab скрипт

Неужели ты хочешь сказать, что сувать sudo в юзерский крон вместо того чтобы прописать команду в рутовый - это хорошая практика? Зачем ты удалил моё сообщение, чтобы автор темы по вредным светам устраивал бардак у себя в системе?

Задача: минимизировать вероятность генерации (в неопределённом будущем) поддельного контента, подходящего под некий хэш.

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

В связи с этим возник вопрос, я даже не уверен что он действительно относится к security а не к толксам (если нао перенесите). Допустим, на хэш нам выделено 512 бит, и мы решили выбрать sha512. Можно предположить, что когда-нить к нему подберут алгоритм подбора подходящих исходных данных, придумав способ непротиворечиво разврачивать данные из хеша назад по цепочке (разумеется, подходящих разных данных очень много, но допустим даже нашли способ развернуть один единственный вариант - этого достаточно). И другой вариант: допустим, 256 бит мы займём sha256, а оставшиеся - ещё каким-нить 256-битным хэшом, построенным на немного других математических принципах. Кажется (именно кажется, а как на самом деле я не претендую знать), что этот вариант выглядит немного надёжнее: даже найдя алгоритм разворота sha256, придётся потом ещё искать такой же алгоритм для второго хэша (а учитывая что он математически другой - искать придётся с нуля заново), а так же как-то обеспечить чтобы оба агоритма сгенерили одинаковые данные.

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

-------- Уточнения:

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

2) Советы исключительно утилитарного характера «используй то, оно хорошее» не нужны, интересует именно сравнение.

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

Обычно h264 упакован в контейнер, например mp4, и в этом контейнере (в блоке moov или moof) указывается pts (presentation time) каждого кадра, то есть порядок их показа. Допустим, moov куда-то потерялся, но остался блок mdat, в нём сырой h264. В нём есть информация о порядке кадров или никак нет?

Когда я сконвертировал mp4 в annexb (тоже можно считать без контейнера) - mpv получившийся файл успешно показывал, и вроде даже нормально выглядело. Хотя, допускаю, что кадры там показывались в порядке кодирования, а я просто не заметил разницы от мелких перестановок.

В ходе неспешной разработки vcs пришла в голову такая идея, но я не уверен что она полезная, вот хочу узнать чьё-нить мнение.

Введение (это не вопрос ещё):

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

Теперь собственно вопрос. А что, если:

1) право публикации привязать не к одному ключу владельца, а к набору ключей ответственного за публикацию коллектива, и для валидной публикации требовать наличие подписей всех участников, либо какого-то порогового процента их количества

2) список ответственных подписей версионировать, то есть в ревизии номер 137 будет информация о том, как именно должна быть подписана ревизия номер 138

3) для смены информации о правах публикации (список участников и правила подсчёта достаточных голосов) всё та же процедура с подписями, но, возможно, более высокое их пороговое количество, или обязательное наличие среди списка подписей подписи «председателя» (которую, вероятно, тоже можно сменить); при этом так же возможна процедура одностороннего отзыва своего членства - такую ревизию достаточно подписать только одной подписью - того человека, который самоустраняется (хотя тут проблема - это может спровоцировать недопустимое ветвление, возможно нельзя одной и должны одобрить остальные)

На мой взгляд, выглядит красиво, криптографически обеспеченная преемственность, но есть ли тут полезные применения?

С одной стороны, видится полностью отвязанная от физического хранилища сущность, добавление информации в которую делается не на основании доступа к конкретному серверу, а на основании криптографического разрешения. С другой, на практике скорее всего всё равно получится некий сервер с урлом, который люди будут воспринимать как первоисточник, и на котором никто не помешает написать что-то типа «ой, у нас проблемы, старые ключи отменяются, новые такие». Ну или другим способом сделать «хард форк». Даже более того, в этом может возникнуть нужда: какие-нить диверсанты могут в результате многолетней секретной операции по внедрению получить достаточный для принятия любых решений комплект подписей, и испортить проект - не хоронить же его после этого? Ну или просто тупо украсть или отнять ключи у настоящих участников, что может теоретически случиться даже весьма быстро. Или текущие участники могут забить или пропасть без вести.

Что думаете?

Перемещено dataman из security

При запуске гуи-проги (вроде бы - только использующей видеоускорение), на весь экран (размер рабочей зоны окна 1920х1080), xorg начинал жрать 100% проц и подавать признаки жизни раз в 15-20 секунд (выглядело как зависший комп). Если окно открыто не на полный экран, а хотя бы чуть поменьше, или если его видимая зона перекрыта другим окном (я проверял таскбаром, у него ширина около 300 пикселей, другое было бы делать долго и я не стал) - проблема не проявлялась.

После перезапуска xorg-а всё стало норм как и раньше.

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

Касательно того что именно за прога: заметил на xscreensaver, но некоторые лагали, некоторые нет, лагали те что с opengl. Потом пробовал запустить фулскрин mpv - он тоже лагает. xev не лагал, xfce4-terminal не лагал, хотя у последнего ещё меню сверху, возможно оно не «считалось» за размер окна.

Видео nvidia с проприетарным драйвером 490.

В логах dmesg и Xorg.log на момент лагов пусто.

Кто-нить сталкивался?

Диски Seagate ST8000AS0002 (несколько штук, были куплены вместе, работали тоже вместе). По логам обнаружил, что power on hours у них обнулился после примерно 78190 часов, то есть без 4 недель 9 лет. Что это за странное число такое? В побайтовом дампе смарта оно у этих дисков хранится в младших 32 битах поля «raw» в виде часов, то есть это не из-за того что там были минуты или секунды или ещё что-то.

Кто-нить сталкивался?

После запуска иксов он делают мне 3840x1080, рисуя две его 1920х1080 половины на разных видеовыходах. Одноразово исправляется командой

$ xrandr --output HDMI-0 --pos 0x0

$ xrandr --output VGA-0 --pos 0x0

Как это полностью отключить? Подозреваю, что можно в xorg.conf прописать эти pos вручную (кстати, не знаю как). Но лучше не это, а именно вообще отключить этот виртуальный экран, чтобы вне зависимости от конфигурации видеовыходов он никогда не пытался такое делать. Есть такое?

В иксах с помощью xrandr переключается на лету между VGA и HDMI, как сделать то же самое для ядерной консоли? Знаю про прописывание аргументов в grub, но там нужно ребутаться, другие варианты есть? И ещё, желателен режим чтобы на всех видеовыходах была одинаковая картинка (то есть чтобы сделать 1 раз и больше ничего не переключать) - такое можно настроить хоть как-нить?

%Cpu(s): 10,7 us,  4,3 sy,  0,0 ni,  0,0 id, 82,6 wa,  0,0 hi,  2,3 si,  0,0 st

Вопрос вот про «wa». И кстати почему оно считается состоянием проца вообще? Ведь пока процесс ждёт ответ от диска, ядро проца вполне может заниматься чем-то другим. В фрибсд например iowait не считается занятым ядром и в детализации занятости проца его нет.

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

Перемещено hobbit из general

Когда подключаю новому диску сата-питание - система теряет (и спустя какое-то время снова находит) диск, подключённый уже раньше к тому же проводу. Ну и слышно как он останавливает шпиндель. Диски, подключённые к другим проводам, не теряются. В некоторых комбинациях дисков (уже включённый и новоподключённый) этого не происходит, но в целом чаще кажется происходит чем нет. Это норм?

Лет 10 назад на старых дисках (blue и подобных на 250гб и меньше) такого ни разу не замечал.

Купил новый хороший БП с большим запасом мощности, засунул в соседний молекс на 5В и 12В линии по low-esr конденсатору 2200мкФ - не помогает ничего.

У меня стандартная процедура доступа к этому счётчику на WD40EFPX (Red Plus 4TB) не работает, диск собственно отклоняет команду его чтения. Я её шлю не через idle3-tools а через фрибсдшный camcontrol в виде блоба байт, но это не важно. На старых дисках (например WD20EFRX Red 2TB, 2015 года) всё работает. А ещё я в инете нашёл жалобы на аналогичную ошибку и из idle3ctl и из hdparm -J, но нигде не нашёл внятные ответы на эти репорты. Может кто на ЛОРе знает точный ответ?

Хотя радует что конкретно у этого диска таймер явно не 8 секунд, но Load Cycle уже стало 2 вместо 1, так что какой-то он есть, сейчас ставлю опыты. Возможно исправлять его и не требуется, но хотелось бы знать остался ли к нему доступ.

$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +41.5°C  (high = +70.0°C)
                       (crit = +72.0°C, hyst = +70.0°C)

it8718-isa-0228
Adapter: ISA adapter
in0:           1.46 V  (min =  +0.00 V, max =  +4.08 V)
in1:           1.60 V  (min =  +0.00 V, max =  +4.08 V)
in2:           3.26 V  (min =  +0.00 V, max =  +4.08 V)
+5V:           2.98 V  (min =  +0.00 V, max =  +4.08 V)
in4:           3.02 V  (min =  +0.00 V, max =  +4.08 V)
in5:           3.14 V  (min =  +0.00 V, max =  +4.08 V)
in6:           4.08 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
in7:           2.74 V  (min =  +0.00 V, max =  +4.08 V)
Vbat:          3.31 V  
fan1:        1163 RPM  (min =    0 RPM)
fan2:           0 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
temp1:        +42.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:        +51.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermal diode
temp3:        +48.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
cpu0_vid:    +1.050 V
intrusion0:  ALARM

Вот эти in0 in1 итд это что такое? На in6 ещё ALARM какой-то.

Почему пишет +5V 2.98V? Померил вручную на molex разъёме - на 5В нормальные 5В.