LINUX.ORG.RU

Сообщения Bass

 

Удавалось ли кому-нибудь завести Realtek RTL8821AE под FreeBSD?

Ни один из штатных (во FreeBSD 11) драйверов для Realtek, похоже, не поддерживает RTL8821AE.

В результате, в качестве последнего средства, попробовал ndiswrapper.

Драйвера для WinNT 5.1 сконвертировались в ядрёный модуль без ошибок, в выводе утилиты nm вижу символы.

Модули ndis и if_ndis загружены.

Тем не менее, при загрузке полученного модуля в dmesg вижу следующее:

no match for RtlGUIDFromString
no match for ExNotifyCallback
no match for ExCreateCallback
no match for KeInitializeSemaphore
no match for KeReleaseSemaphore
no match for IoWMIQueryAllData
no match for IoWMIOpenBlock
no match for IoCsqInsertIrp
no match for IoCsqRemoveNextIrp
no match for IoCsqInitialize

— и новый сетевой интерфейс, ясное дело, не появляется.

Есть ещё какие-л шаги, которые можно предпринять, или плюнуть и поставить Linux?

 , ,

Bass
()

«Дебианизация» пакета, использующего imake

Приветствую.

Есть античный пакет, в качестве системы сборки использующий imake.

Процесс установки выглядит как make install, но, в отличие от пакетов, использующих autotools, я не могу указать prefix, DESTDIR и вот это вот всё.

Пакет хочется «дебианизировать».

Вопрос: я правильно понимаю, что всю логику установки мне придётся вручную переносить из Imakefile в debian/rules с использованием множества команд debhelper (dh_*), или есть более простой способ?

checkinstall задействовать не хочется — как инструмент он очень ненадёжен.

 , ,

Bass
()

Рисование диаграмм в LaTeX с помощью TikZ

Приветствую.

Пытаюсь освоить ${subj}.

Все примеры ([1], [2], [3]) прекрасно компилируются, но при просмотре dvi-выхлопа блоки на диаграмме отображаются, а все текстовые метки выводятся не внутри блоков, а строго в одной точке (друг поверх друга).

При преобразовании dvi2ps и скармливании результата движку gv диаграмма рисуется частично, текст не отображается вообще, в сообщениях следующее:

Error: /undefined in VResolution
Operand stack:
   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   0.12   72
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval-- GPL Ghostscript 9.20: Unrecoverable error, exit code 1
  --nostringval--   --nostringval--   false   1   %stopped_push   1999   1   3   %oparray_pop   1998   1   3   %oparray_pop   1982   1   3   %oparray_pop   1868   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1209/1684(ro)(G)--   --dict:1/20(G)--   --dict:87/200(L)--   --dict:171/300(L)--   --dict:58/200(L)--
Current allocation mode is local
Last OS error: Resource temporarily unavailable

В то же время pdflatex обрабатывает исходный .tex-файл без проблем, на выходе не диаграмма, а конфетка.

Вопрос: это такое хитрое ограничение TikZ, что он не работает с dvi-форматом?

Debian 9, texlive-full установлен.

 , ,

Bass
()

Как изменить имя и почтовый адрес, используемые dch

Собственно, ${subj}.

При обновлении debian/changelog dch вставляет моё имя из /etc/passwd и генерит почтовый адрес как ${LOGNAME}@${HOSTNAME}.

Хочется поменять это поведение.

Сильно не бейте — я нуб, и Too Many Fucking Manuals to Read.

 , ,

Bass
()

Чем заменили Xprint?

Была раньше такая технология (https://www.x.org/docs/XPRINT/Xprint_FAQ.html).

Насколько я понимаю, любой клиент мог воспользоваться принтерами, подключёнными к X-серверу (вплоть до печати просто содержимого окна), через вызовы клиентской библиотеки libXp.so и отдельный экземпляр X-сервера, отвечающий за собственно печать (Xprt).

Насколько я понимаю, CUPS, cairo и вот это вот всё — вещи сугубо клиентские.

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

Возможно ли технически собрать Xprt из современного кода Xorg? Сохранились ли этот сервер и сопутствующие утилиты в портах *BSD (кастую iZEN)?

 ,

Bass
()

/tmp/serverauth.MPuME5LguK в качестве XAUTHORITY

Вот, собственно, такой вопрос.

Несмотря на существование файла ~/.Xauthority и на явно выставленное окружение (XAUTHORITY=~/.Xauthority), X-сервер всегда стартует с аргументом -auth, указывающим на случайный файл в /tmp (см. заголовок).

Это, разумеется, если не переопределить иное (через ~/.xserverrc).

Вот скажите — вот нафига так? У меня же один и тот же файл спокойно может обслуживать несколько разных значений переменной DISPLAY.

Update: cast Zubok.

 ,

Bass
()

e2fsck: checksum doesn't match extent

Приветствую.

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

Запуск debugfs привёл к вот таким файлам:

# debugfs -R 'ncheck -c 125090 135942 146377 149354 149355 154279 155520 178619 179280 280807' /dev/mapper/unit--725--vg--bulk-public 
debugfs 1.43.4 (31-Jan-2017)
Inode   Pathname
125090  /distfiles/mozilla/seamonkey/seamonkey-2.49.1/obj-x86_64-pc-linux-gnu/dist/seamonkey/libxul.so
135942  /distfiles/mozilla/seamonkey/seamonkey-2.49.2.source.tar.xz
146377  /distfiles/mozilla/seamonkey/seamonkey-2.49.1.source.tar.xz
149354  /distfiles/mozilla/seamonkey/seamonkey-x86_64-pc-linux-gnu-gtk2+alsa-2.49.2.tar.bz2
149355  /distfiles/mozilla/seamonkey/seamonkey-2.46.source.tar.xz
154279  /Java/IDEA/ideaIU-2017.2.6-no-jdk.tar.gz
155520  /Java/JBoss/6.1/jboss-as-distribution-6.1.0.Final.zip
178619  /distfiles/mozilla/seamonkey/seamonkey-2.46/obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so
179280  /distfiles/mozilla/seamonkey/seamonkey-2.46/obj-x86_64-pc-linux-gnu/dist/seamonkey/libxul.so
280807  /Drivers/HP/LJM1120-Full-Solution.exe

Проверка архивов ошибок не выявила (а libxul.so — да и хрен бы с ним).

И вот тут у меня несколько вопросов.

  • Файлы были записаны давно и долго не менялись, т. е. некорректная контрольная сумма с отключением питания, скорее всего, никак не связана. Раньше раздел проверки fsck успешно проходил. Как контрольная сумма могла «испортиться»?
  • Сами данные оказались корректными (благо, это архивы и можно проверить). Возможно, контрольная сумма была изначально записана неверно. Но, опять же, как?
  • О каких вообще контрольных суммах идёт речь, если, насколько мне известно, ext4 (в отличие от btrfs, zfs и hammer) использует таковые только для метаданных?

 

Bass
()

В ksh93 перестал работать floating point

Собственно, сабж.

Имею два варианта AT&T ksh93 — один 93u+20120801-1 из Debian 8, другой 93u+20120801-3.1 из Debian 9.

Кодовая база, очевидно, почти одна и та же — основной код не меняется уже десятилетиями. В ChangeLog — 3 штуки NMU и всякая мелочь.

Было:

$ echo $((1./2))
0.5

Стало:

$ echo $((1./2))
ksh: 1./2: arithmetic syntax error

Теперь, похоже, единственный шелл, который по-прежнему умеет в FP без внешнего bc.exe — это zsh.

ЧЯДНТ?

 ,

Bass
()

XTerm и кириллица в заголовках окон

Приветствую.

Как известно, есть магическая ANSI escape-последовательность (\e]0;строка\007), позволяющая динамически менять заголовок окна терминала (вернее, одновременно WM_NAME и WM_ICON_NAME, иначе 0 нужно заменить на 1 или 2).

Последовательность поддерживается подавляющим большинством эмуляторов терминалов, в т. ч. и XTerm.

А вот теперь, собственно, вопрос. У XTerm есть ресурс titleModes, описание которого гласит:

       titleModes (class TitleModes)
               Tells xterm whether to accept or return window- and icon-labels
               in ISO-8859-1 (the default) or UTF-8.  Either can be encoded in
               hexadecimal.  The default for this resource is “0”.

               Each bit (bit “0” is 1, bit “1” is 2, etc.)  corresponds to one
               of the parameters set by the title modes control sequence:

               0    Set window/icon labels using hexadecimal

               1    Query window/icon labels using hexadecimal

               2    Set window/icon labels using UTF-8 (overrides utf8Title
                    resource).

               3    Query window/icon labels using UTF-8

Странность состоит в том, что, если ресурс имеет значение 0 (0b00) или 2 (0b10), то всё работает корректно и совершенно идентично (в «не-юникодной локали», в соответствии с ICCCM, выставляются атомы WM_NAME(COMPOUND_TEXT) и WM_ICON_NAME(COMPOUND_TEXT), в «юникодной» же, в соответствии с EWMH, дополнительно к первым двум выставляются _NET_WM_NAME(UTF8_STRING) и _NET_WM_ICON_NAME(UTF8_STRING)).

А вот при значениях 1 (0b01) и 3 (0b11) всё одинаково не работает — escape-последовательность игнорируется (т. е. значение атомов не меняется).

Кто-нибудь может мне растолковать данный ман, а также как с ним коррелирует наблюдаемое поведение?

Спасибо.

 , , ,

Bass
()

Куда делась Emacs-эмуляция в cooledit/mcedit?

Во времена mc 4.5-4.6 был в настройках редактора такой флаг как Key emulation, который можно было выставить в Emacs (F9 -> Options -> General). В файле настроек ~/.mc/ini этому соответствовало

[Midnight-Commander]
editor_key_emulation=1

Затем (кажется, в mc 4.7) флаг из UI убрали, но хотя бы оставили возможность написать в ~/.mc/ini

[Midnight-Commander]
keymap=mc.keymap.emacs

Теперь вот сижу на новомодном mc 4.8, в котором 100500 цветовых палитр, — и хрен. Emacs-эмуляция не работает, и непонятно, как включить.

WTF?!

 , ,

Bass
()

Не работает протокол editres

Есть машина с Debian 9, и есть несколько машин с более ранними версиями (от Woody до Jessie).

Проблема в том, что у X-приложений, запущенных с локальной машины (Debian 9), я не могу запросить ресурсы утилитой editres. Проблема не в самой утилите editres из «девятки» — она прекрасно справляется с клиентами, запущенными с Debian 8 и использующих локальный X-сервер. Совершенно аналогично, editres из Debian 8 работает с клиентами, запущенными с Debian 8 (на локальном X-сервере) и не работает с программами из Debian 9.

Т. е., похоже, какая-то дрянь с клиентскими X-библиотеками (скорее всего, Xt). Но, странное дело, версии библиотеки на Debian 8 и Debian 9 одни и те же (вплоть до sha1-суммы):

$ dpkg-query -W libxt6
libxt6:amd64    1:1.1.5-1
libxt6:i386     1:1.1.5-1

Для сравнения, вот так выглядит editres, когда он «работает»:

https://habrastorage.org/webt/p7/me/qo/p7meqo3rmq98i9nitffrnjguwiy.png

А вот так — для локальных клиентов («Message sent to client asking for widget tree»):

https://habrastorage.org/webt/0h/fw/9_/0hfw9_ah44wknkqfwp6fui52eta.png

Чёрт побери, что они опять сломали в Debian 9?

P. S. Да, ещё важное дополнение. editres из «девятки», слинкованный с /usr/lib/x86_64-linux-gnu/libXaw.so.7, может «спросить» ресурсы сам у себя. Но вот у других клиентов, слинкованных с той же библиотекой (включая другой экземпляр такого же editres) — уже хрен.

 , ,

Bass
()

Использует ли SSH симметричное шифрование?

Про SSL (и TLS) известно, что асимметричная (public-key) криптография используется лишь на этапе handshake — клиент подписывает публичным ключом сервера случайно сгенерированный (симметричный) ключ сессии, и, когда этот ключ безопасно передаётся на сервер, то уже в полный рост идёт шифрование данных каким-нибудь AES256 или, прости господи, 3DES.

Это легко проверить:

$ curl -iv https://linux.org.ru 2>&1 | grep AES
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
$ openssl s_client -connect linux.org.ru:443 -prexit 2>&1 | grep -Ei '(aes|3des|fish)'
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

Ровно так же работает и PGP — сообщение шифруется «ключом сессии», а сам ключ сессии шифруется публичным ключом адресата и отправляется вместе с письмом.

Читаю документацию по SSH — и не нахожу ничего подобного, хотя симметричные шифры (AES, 3DES, ARCFOUR, twofish, serpent, blowfish) вроде упоминаются.

В выводе ssh -v тоже ничего, что напоминало бы о симметричных шифрах:

debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:...
debug1: Host '...' is known and matches the ECDSA host key.
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: Offering RSA public key: ...
debug1: Server accepts key: pkalg ssh-rsa blen 535

Вопрос: использует ли SSH симметричную криптографию, или же всё время идёт шифрование с публичным ключом?

 

Bass
()

Просроченные сертификаты в Builtin Object Token

Приветствую.

Полез давеча посмотреть на сертификаты серверов в SeaMonkey — и увидел 9 штук в Builtin Object Token. Я их поудалял, но они продолжают «висеть» во вкладке «Others»:

https://habrastorage.org/webt/xa/2q/is/xa2qisg6arve5xwmc6tmpcmwrqw.png

Сертификаты просроченные (срок действия истёк в 2014, пример для addons.mozilla.org):

https://habrastorage.org/webt/5f/ry/ox/5fryoxyqavfrl6hcibhnsbzjxuw.png

и, естественно, не отличаются от текущих SSL-сертификатов соотв. сайтов:

https://habrastorage.org/webt/rs/rq/we/rsrqwev0r-wnaujxrpacyf-s0s4.png

Версия SeaMonkey достаточно свежая — 2.46, выпущена в декабре 2016 (кстати, недавняя 2.49.1 ведёт себя так же). В (пустом) заново созданном профиле вижу ровно то же самое:

https://habrastorage.org/webt/5d/ay/ch/5daychmswvrkawglzjk68bp7vfa.png

Вопрос: на кой чёрт браузеру поставлять просроченные сертификаты?

 ,

Bass
()

xdg-open vs run-mailcap, или как вернуться к истокам

Есть у меня пара файлов — .mailcap и .mime.types, и существует эта пара файлов уже почти 20 лет, и тиражируется на все машины.

И уже лет 20 я запускаю run-mailcap %s. И у меня даже есть возможность конфигурировать некую простую логику выбора нужной программы в случае, если есть несколько альтернатив (самый примитивный случай — это разные обработчики в X Window и в консоли), напр.:

text/plain; nedit %s; test=test -n "${VAR}" -a ${VAR} -eq 0
text/plain; vim %s; test=test -n "${VAR}" -a ${VAR} -eq 1
text/plain; gvim %s; test=test -n "${VAR}" -a ${VAR} -eq 2
text/plain; emacs %s; test=test -n "${VAR}" -a ${VAR} -eq 3
text/plain; emacs -nw %s; test=test -n "${VAR}" -a ${VAR} -eq 4
text/plain; mcedit %s;

(Сама форма записи ; test= описана в RFC 1524.)

И работает эта штука достаточно быстро.

Но вот уже лет пять как продвигается альернатива — xdg-open. Которая прекрасна всем:

  1. Пытается определить, какое у меня DE, чтобы запустить «браузер по умолчанию». GNOME? Нет, не GNOME. KDE? Нет, не KDE. XFCE? Опять мимо. Нет, я, конечно, даже глазом не успеваю моргнуть — процесоры нынче быстрые.
  2. По MIME-типу файла пытается найти нужное приложение, распарсив 100500 *.desktop-файлов в /usr/share/applications.
  3. После этого запускает наименее подходящее приложение (напр., для открытия каталогов я использовал thunar (inode/directory; thunar %s; test=test -n "${DISPLAY}")), но вот xdg-open, с*ка, решил, что разумнее запустить git-cola, а затем — audacious (видимо, потому, что в обычных каталогах git-cola возвращает ненулевой код).
  4. Наконец, для программ, у которых отсутствуют *.desktop-файлы, таковые приходится создавать вручную, что однозначно дольше добавления одной строки в .mailcap. Короче, снова приходится настраивать то, что уже годы работало.

Проблема в том, что всё больше инструментов пытаются использовать xdg-open вместо run-mailcap, а сам xdg-open попытается запустить run-mailcap только в случае, если сам не придумает какой-нибудь глупости. Снести xdg-open не получится — от него зависит chromium и ещё куча софта.

Посему вопрос: как сделать, чтобы run-mailcap запускался всегда, и запретить всякие странные эвристики и танцы с бубном?

Для Midnight Commander всё (пока) решается просто:

export MC_XDG_OPEN='run-mailcap'

Для всего остального я, увы, пока вижу лишь

dpkg-divert --divert /usr/bin/xdg-open.orig --local --rename /usr/bin/xdg-open
ln -s run-mailcap /usr/bin/xdg-open

Есть менее радикальные решения?

UPD: Временно решил проблему, создав run-mailcap.desktop след. содержания:

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=run-mailcap %u
Name=run-mailcap
Comment=run-mailcap

и прописав его в качестве обработчика для всех типов в ~/.config/mimeapps.list, но как-то это всё равно через задницу.

 , , ,

Bass
()

Преобразование дискового образа из VHDX (Hyper-V) в VDI (VirtualBox)

Приветствую.

Снёс на работе оффтопик и поставил Linux.

Есть зоопарк виртуальных машин, которые хочется перенести с Hyper-V в VirtualBox. При преобразовании одного из дисковых образов наблюдаю ошибку:

$ VBoxManage clonemedium disk cholera-sda.vhdx cholera.vdi --format VDI
VBoxManage: error: Could not open the medium '/export/vms/cholera/cholera-sda.vhdx'.
VBoxManage: error: VHDX: Image '/export/vms/cholera/cholera-sda.vhdx' has a non empty log which is not supported (VERR_NOT_SUPPORTED).
VBoxManage: error: VD: error VERR_NOT_SUPPORTED opening image file '/export/vms/cholera/cholera-sda.vhdx' (VERR_NOT_SUPPORTED)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MediumWrap, interface IMedium, callee nsISupports
VBoxManage: error: Context: "OpenMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, enmAccessMode, fForceNewUuidOnOpen, pMedium.asOutParam())" at line 179 of file VBoxManageDisk.cpp

Это как-то лечится (в отсутствие инструментов Hyper-V)?

 ,

Bass
()

Debian 9 (Stretch). Первые впечатления олдфага

В качестве лирического отступления скажу, что сижу на Debian года с 2006, когда Debian Etch был ещё в стадии тестирования.

Ниже — список вещей, которые меня неприятно поразили в «девятке» (приятных апгрейдов не было уже давно — субъективно, последней нормальной версией была «шестёрка», или Squeeze).

  • Во-первых, качество инсталлятора за 10 лет нисколько не изменилось. Например, когда в инсталляторе включаешь LVM2, но к штатным логическим разделам нужно добавить ещё отдельные логические разделы для /usr и /opt — за этим приходится идти в консоль. А потом, когда возвращаешься в установщик, он видит, что в логической группе, чёрт возьми, что-то поприбавилось томов, и этот факт ему сносит крышу — базовую систему установить нельзя, потому что на диске есть «незаписанные изменения», а переразбить диск или перечитать тома в группе мы тоже не можем. Алё, дяденьки из проекта Debian, вы там свой продукт вообще тестируете? Вопрос риторический. «Девятка» на ощупь откровенно «сырая».
  • То, что при наличии альтернатив в виде других систем инициализации (sysvinit, openrc, upstart) установщик (в «expert mode», Карл!) ни одну из них не предлагает, меня, как противника systemd, огорчает, но не более того. Это лишь показатель сырости установщика. По умолчанию ставятся базовая система, systemd, sshd и (о, боже!) Wayland с GNOME. Выбрать пакеты индивидуально посредством dselect или aptitude уже давно никто не предлагает. Прогресс требует жертв.
  • А вот то, что при последующей миграции новой системы с systemd на sysvinit внезапно отваливается сетка, потому что для sysvinit нам ещё нужен DHCP client, resolvconf, ifconfig и куча других утилит — это реально неприятно. Т. е. при обновлении предыдущих версий Debian, когда всё уже настроено, этого, конечно, не почувствуешь, а для новых инсталляций, увы, критично. В «восьмёрке» (Jessie), кстати, такого г-на не было — там миграция на sysvinit прошла безболезненно. Здесь хочется заметить, что, если бы полтора фанатика из проекта Devuan не пилили ночами свой мега-дистрибутив с шахматами и поэтессами, тратя свои немногие и потому драгоценные ресурсы на ерунду, а доводили бы до ума Debian — например, тупо запилив альтернативные сборки пакетов, изначально зависящих от libsystemd0, но при этом в рамках проекта Debian и с присущими (когда-то) этому проекту стандартами качества — так вот, многим людям стало бы легче.
  • Xorg отныне не запускается как setuid root. Если хочется запускать «иксы» по старинке, командой startx — то рядовой пользователь словит кучу охренительно информативных ошибок в логе:
    [   419.152] (EE) modeset(0): drmSetMaster failed: Permission denied
    [   419.152] (EE)
    Fatal server error:
    [   419.152] (EE) AddScreen/ScreenInit failed for driver 0
    [   419.152] (EE)
    [   419.152] (EE)
    Please consult the The X.Org Foundation support 
             at http://wiki.x.org
     for help. 
    [   278.970] (EE) Please also check the log file at "/home/bass/.local/share/xorg/Xorg.1.log" for additional information.
    [   278.970] (EE) 
    [   279.016] (EE) Server terminated with error (1). Closing log file.
    
     — а ещё, с ненулевой вероятностью, зависание системы. Зато безопасно. Для нежелающих в дивный новый мир есть костыли в виде пакета xserver-xorg-legacy, который предоставляет setuid-бинарь Xorg.wrap. Теперь у моих «иксов» два конфига — один для сервера, а другой (/etc/X11/Xwrapper.config) — для «запускалки».
  • Поддержка xfs (сервера legacy-шрифтов, а не файловой системы) в libxfont выпилена, потому что несколько лет назад были найдены уязвимости, уже давно закрытые в апстриме. Поэтому из-за прихоти мэйнтейнера пакета я больше не могу поднять у себя сервер и раздавать шрифты дюжине X-серверов в моём личном зоопарке машин.
  • Даже если я не намерен поднимать Wayland, пакеты libwayland и libwayland-bin требуются для gtk+ 3.0 и libegl1-mesa (и, стало быть, косвенно — для X-сервера).
  • При обновлении с Jessie, новый mercurial 3.8.1+ ломает hgsubversion и mercurial-git, если они были ранее установлены.
  • Пропал пакет openjdk-8-jre-jamvm (отдельная реализация JVM). Были проблемы на PowerPC или S/390, и потому пакет выпилили отовсюду. Радикально, чо.
  • tmux 1.9 (Jessie), будучи обновлён до 2.3-4 (Stretch), более не поддерживает кодировки, отличные от UTF-8 (это очень удобно и реально радует, если пытаешься его использовать на тестовой машине, где специально системной локалью выставлена ru_RU.KOI8-R). Он при каждом запуске выставляет stty iutf8, независимо от того, какие у меня самого настройки терминала (bug #885164). Так что теперь я снова счастливый пользователь GNU screen.
  • MySQL заменён MariaDB (без каких-л. альтернатив), что меня несказанно радует, т. к. мне по работе, помимо Postgres, Oracle и MS SQL, нужен именно MySQL, а не клоны. Пакеты MySQL теперь можно взять отсюда: http://repo.mysql.com/apt/debian/dists/stretch. Что характерно, куча софта по-прежнему зависит от default-libmysqlclient-dev, но на самом деле это клиентская библиотека MariaDB (libmariadbclient-dev-compat -> libmariadbclient-dev), которая конфликтует с настоящим libmysqlclient-dev. Так что, если при обновлении с Jessie хочешь оставить себе «полный» MySQL — будь добр снести часть софта, которым пользовался раньше.
  • Пакет dhelp почему-то доступен в Buster, но вот в Stretch не завезли. Забыли, наверное. Ну и ещё штук 20 подобных мелочей. Вроде бы и не критично, но таки неприятно.

Предвижу вопросы вида «что ты сделал для хип-хопа»^W «где багрепорты на все описанные дефекты» и «хрена ли ты тогда ноешь».

Уже пошёл второй десяток лет, как я сижу на Debian. Я честно пытался помогать проекту обратной связью, насколько позволяло время. Но когда количество косяков в новом релизе зашкаливает, понимаешь, что никакого времени не хватит все их задокументировать и добиться исправления. А надо ещё программировать программы руками и кормить семью.

В общем, как однажды сказал классик, сраный «Дебиан» катится в сраное г-но.

Увы.

 

Bass
()

Slack для Debian

По работе возникла необходимость установить Slack (мы же все хипстеры, нам пользоваться почтой и телефоном западло) — и в потрохах deb-пакета узрел примерно следующее (сценарий запихивается в cron.daily).

Т. е. эта дрянь периодически, сама, в обход меня пытается импортировать PGP-ключи и править sources.list.

Нормально ли это? Вопрос риторический.

Т. е. понятно, конечно, что ООО «Slack» со своим говноприложением — полные уроды, и я, конечно же, или перепакую всю эту порнографию, или сделаю chmod 000 на отдельно взятый сценарий (или даже diversion куда-нибудь подальше). Но меня интересует, скорее, другое — как при установке софта из внешних репозиториев отсекать подобные попытки в полуавтоматическом режиме? Не хочется каждый раз выполнять полный аудит при установке не пойми чего.

В частности, могу ли я какие-л. из ключей (по key id) или множества ключей (напр., по какой-л. маске) явно вогнать в чёрный список («web of distrust»)?

 ,

Bass
()

Вопрос по многопоточности в OCaml

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

Lack of parallelism. OCaml does not offer any primitives for parallelism through multithreading. In many cases, this does not affect us because we tend to distribute work between independent processes. But when large in-process caches are needed, it results in high memory pressure. This can only be alleviated by sharing the caches between processes, which is cumbersome and greatly affects code architecture. Having multithreading primitives could let us explore a more diverse range of architectures when developing services.

Отсюда: http://engineering.issuu.com/2015/09/17/ocaml-production.html

С другой стороны, модуль Thread реализован через POSIX threads, и непонятно, откуда указанное выше ограничение:

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

Наконец, интересно, как это всё соотносится с экосистемой F#, у которого на Mono есть вся мощь CLR, а реализация пи этом наверняка опирается на те же pthreads.

Кто проконсультирует?

 

Bass
()

Debian: пропал openjdk-8-jre-jamvm

Был восьмой Debian (Jessie) с подключённым репозиторием jessie-backports.

В какой-то момент установил JamVM (посредством пакета openjdk-8-jre-jamvm) и начал им пользоваться (в тестовом режиме).

В момент обновления на Debian 9 обнаружил, что openjdk-8-jre-jamvm пропал — как из jessie-backports, так и из stretch (хотя остался на bugs.debian.org и packages.ubuntu.com).

Посмотрел в списках рассылки — тишина.

WTF?

 ,

Bass
()

libxfont 1.4.7-2 ломает xfs

Обновляю Debian Jessie из jessie-backports.

Получается обновить всё, кроме libxfont и libxfont-dev, потому что у меня исторически стоит xfs из Wheezy, и я им, чёрт возьми, пользуюсь.

Смотрю ChangeLog и вижу прекрасное:

libxfont (1:1.4.7-2) unstable; urgency=high

  * Pull from upstream git to fix FTBFS with new fontsproto (closes: #746052)
  * CVE-2014-0209: integer overflow of allocations in font metadata
  * CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies
  * CVE-2014-0211: integer overflows calculating memory needs for xfs replies
  * Add breaks on xfs because we broke it by disabling font protocol support
    in 1.4.7.

 -- Julien Cristau <jcristau@debian.org>  Tue, 13 May 2014 17:25:49 +0200

Я правильно понимаю, что они таки сломали поддержку шрифтов X11, доступных по сети?

Нахрена?

WTF?

 , , ,

Bass
()

RSS подписка на новые темы