Можно ли подсунуть smartctl-у бинарный дамп смарта (блоб 512 байт), снятый ранее отдельно (+ указать модель диска), чтобы он его распарсил и показал в удобном текстовом виде?

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

Пример, исходное состояние:

echo greet
./prog1
./prog2
./prog3

первая ветка от него с таким коммитом:

echo greet
echo test
./prog1
./test
./prog2
./prog3

вторая - с таким

echo greet
echo test
./prog1
./prog2
./test
./prog3

Мержим эти две ветки, что должно в итоге получиться?

Вариант [1] - конфликт

Вариант [2]

echo greet
echo test
./prog1
./test
./prog2
./test
./prog3

Вариант [3]

echo greet
echo test
echo test
./prog1
./test
./prog2
./test
./prog3

Или ещё что-то?

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

Я не знаю, какой раздел лучше подойдёт - этот или games, если что переместите.

----- введение, если знаете эту игру и её механику можно пропустить -------

И так, есть такая игра - cookie clicker, её суть (если опустить несущественные для задачи аспекты - их там много, но давайте их не обсуждать тут) такова: есть некий счёт, и он автоматически растёт каждую секунду на величину cps, которая зависит от того, какой набор «построек» куплен (покупка построек делается как раз с оплатой из этого счёта). Постройки есть разных типов, для удобства представим что их всего два (постройка типа A и постройка типа B). У каждого типа постройки есть:

- цена, стартовая за первый экземпляр, и дальше каждый следующий в k=1.15 раз дороже - геометрическая прогрессия

- прибавка к cps, которая даётся при покупке очередного экземпляра: если купить 10 построек, они дадут в 10 раз больше cps чем если купить одну, то есть каждое следующее добавление одного и того же cps получается дороже

Итого, текущее состояние описывается текущим счётом, количеством построек типа A и количеством построек типа B.

---------- собственно задача ------------

Текущий счёт у нас нулевой (только что всё потратили), и имеется некоторое cps = x0. Для покупки доступны две постройки:

Первая (A), с текущей ценой за штуку y1 и дающая прибавку x1 за ту же штуку.

Вторая (B), с текущей ценой за штуку y2 и дающая прибавку x2 за ту же штуку.

Первая дешевле (y1<y2), даёт меньше cps (x1<x2) и имеет худшее отношение цена/качество (y1/x1>y2/x2). Очевидно, если захотеть купить хоть что-то, то её мы сможем купить раньше - она дешевле. Вопроса два, простой и сложный.

Первый: мы хотим купить одну штуку A и одну штуку B, покупаем как только накопим. В каком порядке их надо купить чтобы быстрее добиться цели?

Второй: мы хотим максимально быстро поднять cps до некоторой неуказанной величины. Сколько раз надо купить постройку A перед первой покупкой постройки B? (формулировка не идеальная но надеюсь понятно о чём речь)

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

Найти удовлетворяющий требованиям ответ на второй вопрос мне найти пока не удалось, думаю будет интересно и недоделанные решения посмотреть.

Заголовок покороче придумать не смог.

При работе в консоли, обычно (но, к сожалению, не всегда), можно набирать заранее весь нужный клавиатурный ввод, а софт его сам, когда надо, прочитает и обработает. К слову, в ДОСе это работало ещё чаще чем в консоли современных юниксов, но там был маленький буфер ввода всего на 16 (или 32, не помню) нажатий.

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

1) нажать хоткей (или у кого-то кнопку) запуска терминала

2) подождать пока он запустится

3) набрать в нём команду и энтер

4) подождать пока запустится фф

5) набрать в нём адрес и энтер

Если не уделить должного внимания пунктам 2 и 4, ничего хорошего не получится. Хуже того, начавшее появляться окно фф не означает что 4 пункт сделан, надо ждать пока появится курсор в адресной строке.

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

Неужели никто не пытался это исправить? Есть ли какие-то общеупотребительные подходы?

В терминалах кстати это тоже бывает, некоторый софт сжирает весь текущий stdin без намерения его как-то обрабатывать, но пожалуй это другая тема.

Я что-то раньше не обращал внимания, а в линуксе локалхостовые роуты где-то списком можно посмотреть (ну кроме ifconfig чтобы узнать оттуда айпишники всех интерфейсов)? В фрибсд они в таблице роутинга наравне с остальными присутствуют. Имеется ввиду что вот допустим у компа есть локальный адрес 192.168.1.77 и в таблице будет что адрес 192.168.1.77 доступен через lo. Ну и 127.0.0.1 аналогично.

Насколько у меня отложилось в памяти, на каких-то древних системах readdir() возвращал данные в статическом буфере, общем на весь процесс, то есть код вида

{
  DIR *dp1, *dp2;
  struct dirent *a, *b;
  //....
  a = readdir(dp1);
  printf("name1 = %s\n", a->de_name);
  b = readdir(dp2);
  printf("name2 = %s\n", b->de_name);
  printf("name1 = %s\n", a->de_name);
  //....

Кто-нить помнит о каких системах речь и где об этом почитать? Или это всё чисто теория и в реальности таких систем не было? Или я вообще всё это выдумал и нигде такого не упоминалось?

Наберите от рута lsattr -al /dev/ только на всякий случай на некритичном компе - что произойдёт?

Добавлю что получилось у меня, по /var/log/messages

Nov 28 02:38:39 nb2 kernel: [4438721.540616] NET: Registered protocol family 40
Nov 28 02:38:39 nb2 kernel: [4438721.613867] tun: Universal TUN/TAP device driver, 1.6
Nov 28 02:38:39 nb2 kernel: [4438721.683373] Non-volatile memory driver v1.3
Nov 28 02:38:39 nb2 kernel: [4438721.877780] Btrfs loaded, crc32c=crc32c-intel
Nov 28 02:38:39 nb2 kernel: [4438721.935117] serial 00:02: LSR safety check engaged!
Nov 28 02:42:14 nb2 kernel: [    0.000000] Linux version 5.10.0-26-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.197-1 (2023-09-29)
Nov 28 02:42:14 nb2 kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-26-amd64 root=UUID=b595a138-37e4-4775-8edd-27e7455d14a1 ro acpi_backlight=vendor "acpi_osi=!Windows 2012" module_blacklist=echi_pci,ehci_hcd quiet

Как видно, lsattr подгрузил пачку каких-то ненужных модулей. А через некоторое время (секунд 15?) ноут молча ребутнулся, похоронив открытые окна за полтора месяца :(.

Корень причины понятен: в отличие от нормальных людей, у которых файловые флаги отдаются через stat(2), в линуксе чтоб их получить надо делать какое-то ioctl на открытый файловый дескриптор (и открывание с O_PATH не годится). Отсюда последствия: 1) на симлинках не работает, 2) попытка чтения их из chr/blkdev или pipe может иметь побочные эффекты т.к. открывание таких файлов их имеет (но в итоге всё равно фейлится, по крайней мере для файлов устройств). Тут кстати, неустранимый race получается - невозможно пытаться прочитать флаги, будучи уверенным что не откроешь случайно файл какого-нить устройства. Хорошо хоть следовать по симлинкам можно запретить через O_NOFOLLOW, а то было бы совсем печально.

Механизм конкретно моего сценария - точно не пойму, но есть два предположения: 1) грузится какой-то забагованный модуль (не обязательно из тех четырёх, ведь они могут и молча грузиться не отправляя ничего в dmesg) который спустя недолгое время роняет ядро 2) активируется какой-то hw watchdog, который допустим надо после этого оповещать раз в 10 секунд для избежания аварийных ребутов

Раньше я делал read() на 1048576 байт, в gstat он показывался как 8 чтений по 131072 байт, которые отправлялись очередью. После обновления 12 -> 13 в gstat оно стало видно как 1 чтение 1048576 байт, и ухудшилась скорость работы. Такая зависимость скорости от размера блока - будем считать, особенности железа, речь не про неё.

Вопрос вот какой - почему оно раньше нарезало мегабайт на части а теперь перестало, как вернуть старое поведение? Вручную делать 8 read-ов вместо одного не годится, тогда каждый следующий ждёт ответа от предыдущего и не работает hw очередь запросов.

Это всё с O_DIRECT если что, а диски multipath.

Уточнения:

1) от multipath не зависит.

2) несмотря на O_DIRECT он походу делает read-ahead, потому что см. ниже

проверял dd iflag=direct с разными bs

размер в read()     размер в geom было - стало
1K                  32K            32K
2K                  33K            33-34K
4K                  35K            36K
8K                  39K           42K
16K                 50-51K         62K
32K+                128K           1M

Если кто захочет у себя потестить, код для узнавания размера geom-чанка

while true; do X=`gstat | grep -F тут_шаблон_для_грепа_строки_с_нужным_диском` ; rs=`echo $X | awk '{print $3}'` ; kbs=`echo $X | awk '{print $4}'` ; bs=`expr $kbs / $rs` ; echo "$rs $kbs $bs"; done

Само чтение:

dd iflag=direct if=путь_к_большому_файлу_на_нужном_диске of=/dev/null bs=1024

Спустя долгое время (месяц? разное наверно, не засекал) работы вкладки куда каждую секунду обновляется дашборд текущих 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 ?