http2.github.io - что это за бред? Серьёзно, они своей домашней страницей решили сделать аккаунт на гитхабе? Или это кто-то левый мимикрирует?

Последнее время стала раздражать тормознутость rdp-сеансов через remmina (на том конце xrdp, если что). Сначала думал что виноваты новые версии xrdp, но догадался запустить старую версию реммины которую не удалил. Так вот, там где 1.1.2 (+freerdp 1.1.0-beta1) работает нормально и укладывается в 5кбайт/с входящего трафика, 1.4.11 (+freerdp 2.3.0) хочет 100кбайт/с и больше и тормозит. Если поставить на паузу коннект (на уровне tcp) и вернуться через несколько часов - то приходится долго смотреть как на удалённом десктопе часы пересчитывают все минуты от начала до конца паузы. Причём - если все удалённые окна были спрятаны, то часы идут ещё относительно быстро, а если там был открыт браузер (даже без меняющихся картинок) - то это очень надолго. С 1.1.2 такого никогда не было - казалось что оно после долгих задержек просто перерисовывает экран целиком в новое состояние, не проходя все промежуточные. А может быть просто очень быстро проходит и незаметно. В настройках коннекта ничего интересного не нашёл.

В чём может быть дело?

А да ещё вспомнил уточнения. В debian jessie было 1.1.1 и работало нормально. Потом в buster было 1.3.3 и работало вообще неудовлетворительно - не помню в чём было дело, но пользоваться было вообще невозможно, откатил на 1.1.1 через полчаса попыток наладить её работу, а спустя какое-то время пересобрал 1.1.2 из исходников чтобы не зависеть от библиотек из debian 8. Затем вышел bullseye с этим 1.4.11, который поначалу понравился но затем выяснилась эта подстава.

По мотивам комментария LINUX-ORG-RU: Мир поменялся (комментарий)

К слову, раз уж пошла пьянка и в забугром приняли законы позволяющие прогнать GPL код через сетку и получить Publick Domain результат, то есть вероятность что остальные в мире будут к подобному подтягиваться. Есть мысль включать в лицензии личных публичных проектов запрет на использование исходного кода в качестве данных для обучения и процесс работы программы тоже. Только нужно грамотно сформулировать и добавить это условие в любые лицензии своих проектов к MIT можно просто дописать, в случае GPL и подобных которые нельзя менять включить второй лицензией и пользователь обязан принять обе или тип того.

Собственно что вы думаете о реализации и целесообразности такого?

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

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

Насколько, по вашему мнению, целесообразно добавление подобных пунктов в лицензии:

1) свободные пермиссивные, не имея побочных эффектов;

2) свободные с копилефтом, теряя лицензионную совместимость с много чем

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

А может, всё не так страшно и пусть воруют код? Или же, может быть, подобные вещи должны регулироваться законами, а не лицензиями?

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

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

Вышла версия 1.3 набора программ fwmx, включающих в себя собственно оконный менеджер (fwm), меню запуска приложений и регулятор громкости. В качестве индикатора раскладки используется xxkb.

( читать дальше... )

>>> Подробности

Хочу без привязки к конкретному случаю поддерживать все виды представлений пикселей, которые X-сервер теоретически может подсунуть. В частности, нужно выполнить весьма простую задачу: прислать с клиента на сервер картинку. На клиенте в иксах картинки принято представлять с помощью XImage.

По идее надо сделать XCreateImage:

XImage *img;
img = XCreateImage(display, NULL, depth, ZPixmap, 0, (char*)data, width, height, bitmap_pad, bytes_per_line);

И тут же сразу проблема: величина bytes_per_line, да и размер памяти, который надо выделить под data, зависят от количества бит на пиксель. Ну и чтобы в data что-то записывать, их тоже надо знать. Понятное дело, что для 32-битного depth оно будет тоже 32, но в общем случае, как видно из исходников, XCreateImage для узнавания этого значения использует функцию _XGetBitsPerPixel() и затем записывает её ответ в img->bits_per_pixel (вообще можно было бы оттуда это значение и прочитать, но его надо знать уже заранее).

Несмотря на то, что она есть в /usr/include/X11/Xlib.h, смущает тут подчёркивание в начале названия этой функции, отсутствие мана к ней и то, что поиск по её названию в инете выдаёт только всякую ерунду и отсылки к исходникам Xlib. Насколько она официально публичная?

Тут вот пишут что она неофициальная, но поскольку без неё всё это сделать нормально невозможно то надо вызывать: https://bugs.launchpad.net/hf-lab/ bug/716239

С другой стороны, странно: не могу придумать, как вообще можно нормально использовать XCreateImage с немонохромным типом без знания этой величины (можно ненормально: вызываем с data=NULL, затем читаем img->bits_per_pixel и вручную ставим img->data). Вряд ли они сделали заведомо нерабочую (в рамках официальных спек) функцию в интерфейсе и за 30 лет это заметили только несколько раз.

Я естественно понимаю, что вряд ли _XGetBitsPerPixel() уберут, но интересует скорее идеально-теоретическая сторона дела с поддержкой всех вариаций X11 с начала времён.

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

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

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

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

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

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

Если вы участвуете более чем в одном проекте, то сложите все задействованные продукты.

Возможно ли такое? Хочу себе сделать, но лень разбираться, т.к. не уверен что это вообще штатно возможно. Может кто видел аддоны которые таким занимаются? (чтоб точно знать что можно, ну и смотреть их код как пример)

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

Извиняюсь за оффтоп, речь про компилятор 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