Извиняюсь за оффтоп, речь про компилятор ms vc 5 (вроде, 97 года).

Если в большой программе где-то в начале вставить бесполезное typedef int random_string_5423432; или int func_name_35432423(void); (в том числе не задевая номера строк), то у него (иногда, но всегда репродуцируемо) меняется ассемблерный дамп получившегося бинарника. Оба варианта (до и после) корректные, отличия касается, например, выбора другого регистра для хранения какого-нить промежуточного числа или другого порядка сложения/вычитания в формуле a[b-c]. Или, например, вместо add eax,[some_mem] оно делает mov ecx,[some_mem] / add eax,ecx или наоборот.

Зависимость наблюдается от количества таких вставок, их содержание не важно. То есть, допустим, нет вставок - один бинарник, 5 typedef-ов - другой, 12 typedef-ов - третий, 3 typedef-а и 2 функции - такой же как 5 typedef-ов. Дублирующие объявления не влияют (т.е. если написать typedef int q1; typedef int q1; то это то же самое как если бы он был один.

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

Другие версии msvc не проверял. В gcc с таким не встречался вроде (или плохо смотрел).

Мне вот захотелось поставить одной новости фейспалм, а потом я подумал что автор может воспринять его на свой счёт и убрал. А как вы воспринимаете их? Это реакция на то, о чём говорится в новости, или на то, как её автор донёс до лора?

А вы знали? Случайно нажал ища хоткей для переключения вкладок xfce-terminal.

Давно не устанавливал новые линуксы, вот установил и обнаружил что там pid-ы стали из 6 цифр. При этом на компах где уже стоит тот же debian 11 (обновлённый со старых) - pid-ы везде короткие. Выяснил что это настраивается в /proc/sys/kernel/pid_max и что на 32-битных он по-дефолту 32768, что проясняет почему у меня на старых компах они короткие. Но мне помнится, я когда-то и 64-бит линуксы где-то ставил и там тоже были короткие pid-ы.

Имеется ввиду прямо правка изменённого текста, включая номера и количество строк в заголовках. У меня - иногда бывает. Причины могут быть разные, я вот вспомнил две:

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

2) сгенерил сам патч на одной системе, перенёс в другую, приготовился применять, а потом внёс ещё небольшие правки в код - вместо того чтобы заново генерировать и пересылать патч, проще бывает эти правки сделать прямо в нём на системе куда он прислан.

Насколько я вижу в man sshd_config, форваринг unix-сокетов разрешается опцией AllowStreamLocalForwarding и больше никаких настроек там не причастно. По факту же, если в конфиге указана опция PermitOpen и в ней стоит что-то кроме any, форвардинг unix-сокетов всегда отвергается с надписью типа такой:

Received request to connect to path /path/to/socket, but the request was denied.

Собственно, посмотрев в исходник, всё так и есть: для unix-сокетов там точно так же вызывается проверка белого списка, только вот способов внести в этот белый список unix-сокет (кроме общего для всех any) я что-то не вижу. Ну и с маном это поведение кардинально расходится (кроме того что синтаксис PermitOpen рассчитан только на TCP).

Проверял на 7.9 (дефолтный в freebsd12) и 8.4 (дефолтный в debian11).

Это я что-то напутал или всё так и есть и уже за много вышедших версий никто даже не заметил проблемы?

---------------------------------------------------

Места в исходниках (8.4 но думаю там мало что менялось):

1) serverloop.c: server_request_direct_streamlocal()

        if ((options.allow_streamlocal_forwarding & FORWARD_LOCAL) != 0 &&
            auth_opts->permit_port_forwarding_flag &&
            !options.disable_forwarding && (pw->pw_uid == 0 || use_privsep)) {
                c = channel_connect_to_path(ssh, target,
                    "direct-streamlocal@openssh.com", "direct-streamlocal");
        } else {
                logit("refused streamlocal port forward: "
                    "originator %s port %d, target %s",
                    originator, originator_port, target);
        }

2) channels.c: channel_connect_to_path()

        permit = pset->all_permitted;
        if (!permit) {
                for (i = 0; i < pset->num_permitted_user; i++) {
                        perm = &pset->permitted_user[i];
                        if (open_match(perm, path, PORT_STREAMLOCAL)) {
                                permit = 1;
                                break;
                        }
                }
        }

static int
open_match(struct permission *allowed_open, const char *requestedhost,
    int requestedport)
{
        if (allowed_open->host_to_connect == NULL)
                return 0;
        if (allowed_open->port_to_connect != FWD_PERMIT_ANY_PORT &&
            allowed_open->port_to_connect != requestedport)
                return 0;
        if (strcmp(allowed_open->host_to_connect, FWD_PERMIT_ANY_HOST) != 0 &&
            strcmp(allowed_open->host_to_connect, requestedhost) != 0)
                return 0;
        return 1;
}

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

Он до сих пор (с выпуска bullseye прошло уже полтора года) не видит эту ветку.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992258

Может кто-то знающий перл поможет им пофиксить это?

https://salsa.debian.org/webmaster-team/packages/-/tree/master/

Как я понимаю он 30 сек, видимо в драйвере sata а может и нет. Как сделать больше?

[1867460.020987] sd 0:0:0:0: [sda] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=34s
[1867460.020996] sd 0:0:0:0: [sda] tag#19 CDB: Write(10) 2a 00 15 3d 9b 50 00 00 08 00
[1867460.021002] blk_update_request: I/O error, dev sda, sector 356358992 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[1867460.021020] EXT4-fs warning (device sda8): ext4_end_bio:347: I/O error 10 writing to inode 3945028 starting block 44544875)
[1867460.021040] sd 0:0:0:0: [sda] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=34s
[1867460.021046] sd 0:0:0:0: [sda] tag#18 CDB: Write(10) 2a 00 15 3d 9b 48 00 00 08 00
[1867460.021050] blk_update_request: I/O error, dev sda, sector 356358984 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[1867460.021056] EXT4-fs warning (device sda8): ext4_end_bio:347: I/O error 10 writing to inode 3945030 starting block 44544874)
[1867460.021069] sd 0:0:0:0: [sda] tag#24 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=30s
[1867460.021074] sd 0:0:0:0: [sda] tag#24 CDB: Write(10) 2a 00 0f a1 c1 88 00 00 b0 00
[1867460.021078] blk_update_request: I/O error, dev sda, sector 262259080 op 0x1:(WRITE) flags 0x800 phys_seg 22 prio class 0
[1867460.021141] sd 0:0:0:0: [sda] tag#23 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=30s
[1867460.021146] sd 0:0:0:0: [sda] tag#23 CDB: Write(10) 2a 00 0d 82 5b e8 00 01 a0 00
[1867460.021150] blk_update_request: I/O error, dev sda, sector 226647016 op 0x1:(WRITE) flags 0x0 phys_seg 52 prio class 0
[1867460.021156] EXT4-fs warning (device sda8): ext4_end_bio:347: I/O error 10 writing to inode 2365126 starting block 28330929)
[1867460.021170] sd 0:0:0:0: [sda] tag#22 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=30s
[1867460.021175] sd 0:0:0:0: [sda] tag#22 CDB: Write(10) 2a 00 0d 82 27 90 00 01 a0 00
[1867460.021179] blk_update_request: I/O error, dev sda, sector 226633616 op 0x1:(WRITE) flags 0x0 phys_seg 52 prio class 0
[1867460.021184] EXT4-fs warning (device sda8): ext4_end_bio:347: I/O error 10 writing to inode 2365113 starting block 28329254)
[1867460.021195] sd 0:0:0:0: [sda] tag#21 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=30s
[1867460.021200] sd 0:0:0:0: [sda] tag#21 CDB: Write(10) 2a 00 08 87 60 40 00 00 40 00
[1867460.021204] blk_update_request: I/O error, dev sda, sector 143089728 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0
[1867460.021209] EXT4-fs warning (device sda8): ext4_end_bio:347: I/O error 10 writing to inode 2364663 starting block 17886224)
[1867460.021220] sd 0:0:0:0: [sda] tag#20 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT cmd_age=30s
[1867460.021225] sd 0:0:0:0: [sda] tag#20 CDB: Write(10) 2a 00 08 86 fc c0 00 00 40 00
[1867460.021229] blk_update_request: I/O error, dev sda, sector 143064256 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0
[1867460.021234] EXT4-fs warning (device sda8): ext4_end_bio:347: I/O error 10 writing to inode 2364013 starting block 17883040)
[1867460.021332] Buffer I/O error on device sda8, logical block 36154986
[1867460.021365] Buffer I/O error on device sda8, logical block 36154985
[1867460.021385] Buffer I/O error on device sda8, logical block 19940989
[1867460.021391] Buffer I/O error on device sda8, logical block 19940990
[1867460.021396] Buffer I/O error on device sda8, logical block 19940991
[1867460.021400] Buffer I/O error on device sda8, logical block 19940992
[1867460.021405] Buffer I/O error on device sda8, logical block 19940993
[1867460.021409] Buffer I/O error on device sda8, logical block 19940994
[1867460.021413] Buffer I/O error on device sda8, logical block 19940995
[1867460.021418] Buffer I/O error on device sda8, logical block 19940996
[1867460.022016] Aborting journal on device sda8-8.
[1867460.023588] EXT4-fs (sda8): Delayed block allocation failed for inode 4890023 at logical offset 217412 with max blocks 3 with error 30
[1867460.023596] EXT4-fs (sda8): This should not happen!! Data will be lost
[1867460.023603] EXT4-fs error (device sda8) in ext4_writepages:2855: Journal has aborted
[1867460.031990] EXT4-fs error (device sda8): ext4_journal_check_start:83: Detected aborted journal
[1867460.032000] EXT4-fs (sda8): Remounting filesystem read-only

Про то что диск сомнительно себя ведёт - понимаю, но он уже 5 лет так и не дохнет. А вот эти перемонтирования в ro мешают.

Пока что приходится пользоваться костылём в виде mount -o loop /dev/sda8 /home (после fsck) чтобы поверх read-only home смонтировать его на rw, ничего не выключая.

Последний месяц mpv + yt-dlp перестал видеть звук во всех форматах с раздельными потоками (т.е. работают 18 и 22 только).

Пишет вот такую ошибку

[ytdl_hook] EDL doesn't support fragmentswithout duration with MP4 DASH 
Error in EDL.
EDL: source file 'edl://!mp4_dash,init=(...)' has unknown duration.

Это исправлено этим коммитом mpv. Не смотря на то, что это lua-скрипт, при сборке он засовывается куда-то в бинарник и просто так его не отредактировать. Устанавливать новую (ещё даже не релизную, вроде) версию mpv не всем удобно (в debian testing например версия от января), а возиться с пересборкой тоже не хочется.

Решение: берём исправленный файл ytdl_hook.lua (я скачал исходники apt-get source mpv и внёс в них указанный патч), кладём как ~/.config/mpv/scripts/ytdl_hook.lua и всё работает.

Строчка ошибки

[ytdl_hook] EDL doesn't support fragmentswithout duration with MP4 DASH

Добавление: ещё надо отключить встроенный ytdl_hook.lua, иначе он рандомно переключается с новым и звук работает только в половине случаев.

В файл ~/.config/mpv/mpv.conf надо вписать строку

ytdl=no

Это не один и тот же тролль?

www.linux.org.ru/people/Henry/

www.linux.org.ru/people/SamJohnson/

WTF

Proboval otpravit' comment suda как к произвольному сайту добавить свой css ?

No on ne slalsya poka ne otrezal ot nego polovinu texta.

Redaktirovanie rabotaet idealno esli text to je samii +- probeli no pri popitke sdelat' polnii variant - 502 ili 504

UPD: вроде всё и правда исправилось как ниже написали

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

https://www.sudo.ws/security/advisories/sudoedit_any/

Впрочем, кого это волнует, ведь sudo у всех настроено в режим «разрешать юзеру #1000 всё как руту».

Как описание бага, так и описание этого «sudoedit» намекают на совершеннейшую кашу в головах авторов сей утилиты.

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

Ещё недавно видел тему о том, что какой-то тайлинговый WM научился располагать окна не впритык, а с зазорами. Странное ощущение, когда дефолтная уже 20-30 как лет фича всех WM преподносится как достижение.

Тема не троллинг, я в самом деле не понимаю.

Пытаюсь установить компилятор для cuda (nvidia-cuda-dev) в debian 11, он безальтернативно тянется из amd64 репы. Для i386 нет - это у дебиана так, или оно вообще никак? В чём проблема?

(система OmniOS)

Обычно при добавлении новых физических томов достаточно было сделать format - (номер) - label - y и он был доступен для использования. Сейчас в списке дисков для настройки вместо типа (где какие-то буквы, заканчивающиеся его размером) пишет «drive type unknown», когда я его выбираю - предлагает выбрать тип диска из этого списка:

Bad read of fdisk partition.


AVAILABLE DRIVE TYPES:
        0. Auto configure
        1. Quantum ProDrive 80S
        2. Quantum ProDrive 105S
        3. CDC Wren IV 94171-344
        4. SUN0104
        5. SUN0207
        6. SUN0327
        7. SUN0340
        8. SUN0424
        9. SUN0535
        10. SUN0669
        11. SUN1.0G
        12. SUN1.05
        13. SUN1.3G
        14. SUN2.1G
        15. SUN2.9G
        16. Zip 100
        17. Zip 250
        18. Peerless 10GB
        19. other

Если выбрать 0 (видимо это дефолт) то

Auto configure failed
No Solaris fdisk partition found.

и ничего не даёт делать

format> label
Current Disk Type is not set.
format> fdisk
Current Disk Type is not set.

Можно ввести type - тогда опять появляется список типов. Если выбрать 19 - спрашивает количество цилиндров и ещё какую-то чушь.

Specify disk type (enter its number): 19
Enter number of data cylinders: 
Enter number of data cylinders: 
Enter number of data cylinders: 1
Enter number of alternate cylinders[2]: 
Enter number of physical cylinders[3]: 
Enter number of heads: 1
Enter physical number of heads[default]: ^C

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

Втыкаю модем в порт, он появляется в lsusb и появляются три штуки /dev/ttyUSB[0-2]. Как понять, что вот эти три устройства они именно от той записи в lsusb? Ну, я конечно вижу что оно всё по времени совпадает (втыкание, появление строчки в lsusb и появление устройств), но это похоже на угадывание, а мне хотелось бы чтоб именно где-то чётко было прописано, что вот /dev/ttyUSB0 обслуживается этим usb-устройством. Есть такое?

Ну а вообще это не только модемов касается, всякие флешки /dev/sr0 туда же.

Допустим, у нас есть привилегированный процесс, и он хочет сделать что-то в контексте каких-то непривилегированных прав (и там и остаться). Для этого он переключает себе uid/gid или лезет в контейнер, не важно.

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

Если у нас скрипт и переключаемся на юзера с помощью su, то такой проблемы не возникает: сначала скрипт (форкаясь) делает execve() в su, тот уже с чистой от важных данных памятью делает setuid() и прочее, и потом запускает полезную нагрузку непривилегированного юзера. Но неужели без execve() это никак не сделать? У него есть проблема: ему нужен бинарник в доступном на данный момент файловом пространстве, а если мы например в chroot-е, то там нашего бинарника уже может не быть, либо мы не можем полагаться на его подлинность. Как быть?

Лучше всего подошло бы что-то типа execve-сам-себя, но без указания на файл бинарника (через /proc/self/exe тоже нельзя, потому что в chroot-е его тоже может не быть). Если при этом ещё и можно было передать не только набор текстовых строк, а указать диапазон адресов памяти которые не надо чистить, и точку входа, отличную от main() - вообще прекрасно.

Из-за подлагивающего ssd время от времени (иногда раз в месяц, иногда пару раз в неделю) файловая система не дожидается минутного таймаута и перемонтируется в read-only.

(я сейчас ещё подумал - а может где-то можно увеличть этот таймаут? но тема не об этом)

Допустим, fs у нас уже перемонтировалась, не важно почему. Я сделал ей fsck -f, оно восстановило из журнала (ну или даже если не из него), то есть она теперь в консистентном состоянии. Дальше можно убить все процессы, которые пользуются смонтированное ro-системой, размонтировать её и примонтировать назад как rw, ну либо просто ребутнуть ноут. Этот вариант 100% рабочий, но не всегда удобный. Хотелось бы как-то помягче, хотя бы на время ДО ребута получить к ней доступ на запись.

Понятное дело, перемонтировать ro в rw нельзя, ведь в ядре уже запомнено старое ей (до fsck) состояние и если оно начнёт писать поверх того что сделал fsck, будет плохо. Тут попробовал две идеи, обе провалились.

1) сделать umount -f и смонтировать назад. Нет, пишет umount: /home: target is busy., почему? Вроде как -f означает что надо всем кто ей пользуется сделать битые файловые дескрипторы и принудительно размонтировать, кто может помешать? Вложенных точек монтирования внутри /home нет.

2) примонтировать её второй раз в /mnt/home как rw. Тоже не даёт. Пишет что оно write-protected и поэтому монтирует в ro, даже если указать -o rw.

Что-то можно ещё сделать?

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