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

Если что, я не настаиваю на фиксе, просто решил пофлудить в толксы.

Насколько жизнеспособная идея? Для модема. Короткий (сантиметров 30) я уже сделал и использую, вроде проблем не вызывает. Использовал хорошую 8-жильную витую пару, без алюминия и с 0.52 проводами, по 2 провода на каждый из 4 usb-контактов (всмысле не пару спаял в 1 точку а 2 провода из разных пар). Используется как последние 30 см проводки перед модемом, встроенные в палку на которой он закреплен, дальше идёт обычный usb-кабель, шедший в комплекте с 3g-антенной (антенна оказалась бесполезной, но usb-удлинитель от неё пригодился).

Длины кабеля не совсем хватает (он метра 2), купил активный usb-хаб со своим удлинителем (ещё метра 2) - через него модем стал регулярно терять usb-соединение (при этом он не ребутается, т.е. после пропажи-восстановления /dev/ttyUSB0 по его логам и поведению видно что он продолжает держать ту же регистрацию в сети что у него была, но ppp-коннект разумеется слетает и надо его назад включать). Попробовал взять удлинитель от хаба без самого хаба - то же самое. Вероятно, там плохой провод и я не знаю где взять нормальный. Вот собственно и подумалось что витая пара уж точно качественная, можно просто спаять удлинитель самому, но может я чего-то не знаю и будут проблемы?

upd 2025-11-08

Кабель сделал - одна пара на данные (зелёная, вроде бы с самым коротким периодом плетения), остальные три параллельно на питание. 5 метров - всё работает. В sysfs показывается speed=480

upd ещё

Нет, проблема всё-таки имеется. USB-соединение иногда (редко) стало зависать. Причём зависает странно: приём данных ведётся, отправка прекращается. Спустя какое-то время прекращается и приём (подозреваю из-за того что модем видит отсутствие данных от компа и решает подождать пока комп оживёт). На компе пинг начинает писать про переполненные буферы отправки. В dmesg ничего в связи с этим не пишется. Зависают так одновременно и ttyUSB0 и ttyUSB1. Исправляется перетыкиванием разъёма, само не исправляется.

( echo "q\\"; echo "w" ) | ( read x; echo "$x" )

Выводит qw. Как сделать чтобы обратный слэш прочитался как просто символ, а следующий за ним перевод строки - как конец ввода (как было бы если б не слэш)?

В sh и в bash одинаково съедает слэш, вероятно это posix-поведение.

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

Ченджлог сендмейла из 2021 года

8.17.1/8.17.1   2021/08/17
        Deprecation notice: due to compatibility problems with some
                third party code, we plan to finally switch from K&R
                to ANSI C. If you are using sendmail on a system
                which does not have a compiler for ANSI C contact us
                with details as soon as possible so we can determine
                how to proceed.

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

И zlib:

Changes in 1.3 (18 Aug 2023)
- Remove K&R function definitions and zlib2ansi

И так, есть структура

{
  u8
  u8
  u16  x;
  u16
  u16
  i64
  u64
  u8 [128]
  ...
}

Поле x получилось так что в нём младшие 12 бит и старшие 4 бита используются почти отдельно и приходится везде расставлять &0xFFF. Тянет отделить старшие 4 бита в отдельное u8 поле, но посмотрите насколько фатально это повлияет на дыры из-за выравнивания :( Как быть?

При сборке FreeBSD, с тех пор как в неё всунули шланг (в 9 релизе больше 10 лет назад), этот самый шланг занимает больше половины времени всей компиляции (gcc при этом собирался за какое-то в целом незаметное время). С новыми версиями ситуация усугубляется, если в freebsd-9 он компилировался несколько часов, то в freebsd-13 он сожрал целые сутки уже (в 1 поток). С другой стороны, кто-то мне тут показывал что у него шланг (отдельной прогой и наверно в линуксе) компилировался за умеренное время и примерно столько же как и gcc.

Может кто-нить знает в чём дело (ну кроме того факта что он бутстрапится и таким образом компилируется 2 раза)?

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

И так у меня была репа фрибсд, скаченная 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» в виде часов, то есть это не из-за того что там были минуты или секунды или ещё что-то.

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