У меня что, мало места на экране для оглавления? Это что за вертикальная щель?

https://youtu.be/0shDhqNq1ko

Можно я тут немного разноюсь? Сил блин нет.

Итак, облако Bitrix.

Содержимое папки локально:

$ find 5.\ Раздел\ ПД\ №\ 12\ ч.3-ВОР/*ПЗУ*
5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.2 кн. 1-ПЗУ
5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.3 кн. 1-ПЗУ
5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.3 кн. 1-ПЗУ/Изм_Нов.(12.01.2023)
5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.3 кн. 1-ПЗУ/Изм_Нов.(12.01.2023)/01.1 Титульный лист А4_12.05.2023_СМ3.1.docx
5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.3 кн. 1-ПЗУ/Изм_Нов.(12.01.2023)/03.Содержание тома СМ3.1.docx

Видите лишнюю пустую папку 1. Раздел ПД № 12 ч.2 кн. 1-ПЗУ, которой не должно быть внутри Раздел ПД № 12 ч.3-ВОР? Казалось бы, случайность. Кто-то создал лишнюю папку не в том разделе.

Но таких лишних папок создано 15 штук.

Опять-таки, вы скажете случайность, кто-то создал лишние 15 папок в неверном разделе.

А теперь суть.

Содержимое указанных выше папок в облаке:

5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.2 кн. 1-ПЗУ
5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.2 кн. 1-ПЗУ/Изм_Нов.(12.01.2023)
5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.2 кн. 1-ПЗУ/Изм_Нов.(12.01.2023)/01.1 Титульный лист А4_12.05.2023_СМ3.1.docx
5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.2 кн. 1-ПЗУ/Изм_Нов.(12.01.2023)/03.Содержание тома СМ3.1.docx
5. Раздел ПД № 12 ч.3-ВОР/1. Раздел ПД № 12 ч.3 кн. 1-ПЗУ

То есть файлы переехали в другую папку. И локально это не отображается. Локально они лежат где положено. А в облаке случился бардак.

И между собой они не синхронизируются. Так и лежат несогласованно.

Содержимое самих файлов совпадает.

Утро понедельника начинается не с кофе.

Например:

[root@aquila ~]# ls -l /var/
drwxr-xr-x 21 root root   4096 мая 28 12:51 cache
drwxr-xr-x  4 root root   4096 мая 12 20:42 db
drwxr-xr-x  3 root root   4096 янв  1  1970 dpkg
drwxr-xr-x  5 bin  bin    4096 янв  1  1970 dt
drwxr-xr-x  2 root root   4096 янв  1  1970 empty
drwxrwxr-x  2 root    60  4096 янв  1  1970 games
drwxr-xr-x 67 root root   4096 мая 28 21:09 lib
drwxr-xr-x  2 root root   4096 янв  1  1970 local
lrwxrwxrwx  1 root root     11 фев  1 03:51 lock -> ../run/lock
drwxr-xr-x 17 root root   4096 мая 28 21:48 log
lrwxrwxrwx  1 root root     10 фев  1 03:51 mail -> spool/mail
drwxrwx---  2 root named  4096 мая 24 19:35 named
drwx------  3 root root   4096 янв  1  1970 net-snmp
drwxr-xr-x  2 root root   4096 янв  1  1970 opt
lrwxrwxrwx  1 root root      6 фев  1 03:51 run -> ../run
drwxr-xr-x  8 root root   4096 янв  1  1970 spool
drwxrwxrwt 10 root root  12288 мая 28 21:42 tmp

На самом деле там полный том ФС таких файлов. Как такое могло произойти вообще?

while read commit ; do
    while read path ; do
        echo "$commit:$path"
    done < <( git diff-tree --no-commit-id --name-only "$commit" -r )
done < <( git log --format=format:%H)

Возможно ли то же самое сделать быстрее? Не порождая отдельный git diff-tree на каждый коммит. Для репозитория на 25 тысяч коммитов операция выполняется достаточно долго. Минут 20-30, навскидку.

Существует ли в природе готовое решение для развёртывания zeroconfig content-addressable file storage в локальной сети?

Есть куча файловых архивов, раскиданных на нескольких машинах. Известны их SHA512 суммы. Хотелось бы иметь решение, которое позволяет с минимумом головняков по настройке и админству делать следующее:

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

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

На меня тут gitlab санкции наложил при попытке скачать всю пакетную базу Арча разом:

Клонирование в «cdemu-daemon»...
error: RPC failed; HTTP 429 curl 22 The requested URL returned error: 429
fatal: expected flush after ref listing

Санкции, правда, не долгие, на несколько минут всего. Но.

Всё отлично с переездом Арча на новую репу, кроме того, что теперь непонятно, как засинкать пакеты. Там теперь 11490 репозиториев git, если что.

И я так предполагаю, что на git pull будет такая же шляпа.

Может быть есть какой-то способ цветом выделять различия в новой и старой версии пакета? Какая-нибудь обёртка над пакманом имеет такую фичу?

Т.е. чтобы в строке 1:0.3.71-1 часть 71-1 была выделена, например.

Пакет (22)                      Старая версия      Новая версия       Изменение размера  Размер загрузки

extra/alsa-card-profiles        1:0.3.70-2         1:0.3.71-1                  0,00 MiB         0,03 MiB
extra/antiword                  0.37-9             0.37-10                     0,00 MiB         0,12 MiB
extra/bind                      9.18.14-1          9.18.15-1                   0,20 MiB         1,96 MiB
extra/cpupower                  6.2-1              6.3-2                       0,00 MiB         0,19 MiB
core/curl                       8.1.0-2            8.1.1-1                     0,00 MiB         1,16 MiB
extra/firefox                   113.0.1-1          113.0.2-1                   0,23 MiB        64,62 MiB
extra/graphicsmagick            1.3.40-2           1.3.40-3                    0,02 MiB         2,53 MiB
multilib/lib32-curl             8.1.0-2            8.1.1-1                     0,00 MiB         0,30 MiB
extra/libpipewire               1:0.3.70-2         1:0.3.71-1                  0,01 MiB         0,36 MiB
extra/libwebp                   1.3.0-2            1.3.0-3                     0,00 MiB         0,34 MiB
extra/namcap                    3.4.0-3            3.4.2-1                     0,29 MiB         0,14 MiB
extra/nginx                     1.22.1-2           1.24.0-1                   -0,01 MiB         0,57 MiB
extra/openmpi                   4.1.5-1            4.1.5-2                     0,01 MiB         2,89 MiB
extra/parallel                  20230422-1         20230522-1                  0,00 MiB         0,32 MiB
extra/perf                      6.2-1              6.3-2                       4,41 MiB         8,00 MiB
extra/pipewire                  1:0.3.70-2         1:0.3.71-1                  0,02 MiB         0,62 MiB
extra/python-certifi            2022.12.07-3       2023.05.07-1                0,00 MiB         0,01 MiB
extra/python-fastjsonschema     2.17.0-1           2.17.1-1                    0,00 MiB         0,05 MiB
extra/python-typing_extensions  4.6.0-1            4.6.1-1                     0,01 MiB         0,06 MiB
extra/qt5-base                  5.15.9+kde+r152-1  5.15.9+kde+r153-1           0,00 MiB        13,09 MiB
extra/rav1e                     0.6.3-1            0.6.6-1                     0,57 MiB         1,61 MiB
extra/turbostat                 6.2-1              6.3-2                       0,01 MiB         0,13 MiB

Будет загружено:     99,11 MiB
Будет установлено:  389,85 MiB
Изменение размера:    5,76 MiB

:: Приступить к установке? [Y/n] 

В общем, что хотелось бы:

Тулза для командной строки, которой даёшь тайм-штампы резервных копий и конфиг с правилами ротейта. И она говорит, какие удалить, какие оставить.

То есть не привязанное к какой-то программе, которая реально трогает файлы, а как отдельная реализация алгоритма, просто минимальный кусок кода, завёрнутый в бинарь или в скрипт. Для использования произвольными программами.

Есть что-то подобное, может знает кто?

В продолжение предыдущей темы: Acer Extensa 4220. Еще в строю. Железо то же, ОС та же. На этот раз ОС поставлена на родной 80-гиговый HDD. Который работает на удивление тихо, кстати. Не слышно гула и щелчков, в отличие от более нового 1-терабайтного HDD в ноуте, что стоит рядом на столе.

Я решил выяснить, насколько сложно будет собрать GTK2-версию XFCE на свежем Арче. В AUR нашлась бОльшая часть пакетов. Но некоторых зависимостей не хватало. Я добавил нужное и внёс некоторые правки в имеющееся. Залил сюда: https://github.com/sde-gui/PKGBUILDs-xfce4-gtk2

Кому надо, пользуйтесь, репортите баги и отправляйте пул-реквесты. В AUR запиливать откровенно лень. Это всё еще не максимальный комплект того, что входит в XFCE со всеми допами. Если что-то нужно добавить в сборку, пишите.

На скриншоте видно потребление памяти. XFCE ест больше, чем LXDE/SDE. Для сравнения потребление под SDE: https://ibb.co/HYmnm9r

Еще раз проговорю некоторые моменты относительно потребления памяти и использования Арча на старых машинах:

• Я не проводил никаких оптимизаций и специальных настроек системы. Это Арч как есть + куча разного софта, установленного за годы на исходной машине, откуда он был скопирован (что-то я почистил, но далеко не всё). Задача данной серии экспериментов - посмотреть, насколько пригоден ванильный Арч без тюнинга для работы на Core 2 Duo. Получается, что абсолютно пригоден.
• Это 64-битная ОС. На системах с < 4 ГБ ОЗУ имеет смысл поставить Arch Linux 32, так что потребление памяти еще снизится.
• ОС запущена в контейнере Bedrock-а, и там работают демоны Bedrock-а. Это тоже дополнительные расходы.

И немного личных выводов:

Половину дня провёл за этим ноутом, слушал музыку с ютуба, открывал кучу вкладок с разных сайтов. Правил файлы, работал с git и компилировал пакеты. Производительности машины в целом хватает, но запас по ОЗУ не очень большой. Компиляция кода на Си упирается не столько в CPU, сколько в IO на HDD. Вот если SSD поставлю, там уже в CPU упрусь. GUI не тормозит, работает отзывчиво. Памяти на какой-то из линковок потребовалось много, и около гига улетело в своп. В общем, 3 гига пока всё еще нормально для задач печатной машинки и веб-терминала. Думаю, на 2-х было бы уже сложновато.

P.S. Hobbit, верни тег gtk2 в БД!!!

Простите, но у меня сгорела жопа.

Итак, binutils.

• На гнутой странице проекта нет ни ссылок на релиз ноты, ни даже дат выхода новых релизов: https://www.gnu.org/software/binutils/
• На странице проекта на сорсваре то же самое: https://sourceware.org/binutils/
• Релиз ноты постятся в общетрёпный мейл-лист, в котором это выглядит вот так: https://sourceware.org/pipermail/binutils/2022-February/thread.html Не в отдельный мейл-лист для анонсов, сцуко. Что им млять помешало его завести.
• Единственный способ найти там релиз ноты - это воспользоваться гуглопоиском в надежде, что он достаточно умный. Типа такого: https://www.google.com/search?q=binutils+2.21+released+site%3Ahttps%3A%2F%2Fsourceware.org
• Но вообще это вам не поможет: https://sourceware.org/legacy-ml/binutils/2013-12/msg00027.html
• Если скачать сорцы программы, то релиз ноты там не лежат одним файлом, а разбиты на пять, вашу мать, частей. Патамушта патаму.

$ find . -name NEWS
./gold/NEWS
./gas/NEWS
./ld/NEWS
./binutils/NEWS
./libctf/NEWS

• В релиз нотах нет даты выхода релиза. Хер бы с ней, но напоминаю: на сайте этой инфы тоже нигде нет. Иди гугли мейл-листы.
• У gold собственная система нумерации релизов, не совпадающая с нумерацией проекта. А почему бы и нет?
• В распределении сорцов по каталогам хаос, ничего похожего на адекватную структуру и близко нет. Вали всё кучей, в 1980-м люди экономят время на cd.
• Никакого внятного мануала по сборке из сорцов и по требованиям к системе нет в info-документации. В корневом ./README тоже нет. Внезапно крохи информации есть в файле ./binutils/README. А чо не в ./binutils/I/fukin/love/weird/places/README? Удачи грепать сборочные конфиги, если что-то пошло не так:

$ find . -name configure.ac | xargs wc -cl
   711  22977 ./gold/configure.ac
    80   2528 ./gprof/configure.ac
   239   6841 ./gprofng/configure.ac
    68   1959 ./gprofng/libcollector/configure.ac
  1109  44906 ./bfd/configure.ac
  1053  30229 ./gas/configure.ac
   680  20278 ./ld/configure.ac
   558  15835 ./binutils/configure.ac
  3683 117906 ./configure.ac
   297  11115 ./libctf/configure.ac
   791  22529 ./libiberty/configure.ac
   397  13662 ./opcodes/configure.ac
    77   2355 ./intl/configure.ac
   131   3452 ./zlib/configure.ac
    32    787 ./zlib/contrib/minizip/configure.ac

• У проекта даже есть вики, но зачем она есть, никто не знает: https://sourceware.org/binutils/wiki/TitleIndex

Дело было вечером, делать было нечего, я достал из кладовки артефакт ушедшей эпохи.

На HDD там установлена старая версия Void Linux, которую вряд ли получится без бубна обновить до актуального состояния. Ядро, вроде как, 4.19, и в видеодрайвере там есть баг — при переключении видеорежимов система фризится секунд на 30-40.

Поэтому грузимся с флешки. А на флешке стоит Arch Linux, обёрнутый в Bedrock. Без каких-либо оптимизаций под старое железо и прочих уловок. Обычный актуальный Арч.

Внезапно. Всё работает. Firefox воспроизводит музло с ютуба, LO Writer открывает документы. И даже ушла бага с фризом на переключении видеорежимов.

О системе:

Ядро 6.3.2 в пачсетом zen. Настроен swap в ZRAM. В качестве DE - стек программ на gtk2: LXDE + моя SDE. Терминал — Lilyterm. Параллельно в Бедроке установлен Debian Bookworm с XFCE. Просто чтобы был. Всё это стоит на флешке SanDisk Ultra Flair, которую я таскаю с собой в качестве переносной офисной системы.

О железке:

Экран: 14.1', 1280x800
Чипсет: GL960, Socket P
Процессор:
    Заводской: Intel Celeron 550 @ 2.00GHz; 1 core; Mark 514/626
    Текущий:   Intel Core 2 Duo T6570 @ 2.10GHz; 2 cores; Mark 1254/820
Память:
    Тип: 2 x DDR2 533/667/800* MHz; 3GB Max (2GB в верхний слот + 1GB в нижний слот)
    Заводская: 512MB 667 MHz
    Текущая:   2GB + 1GB 800 MHz (работает на 667 MHz; почему?)

Этот чипсет официально поддерживает только 2 гига. Но может работать и с тремя, если сувать двухгиговую планку в нужный слот. На 4-х уже никак не заводится, что-то там в диапазоне адресов с чем-то конфликтует.

CPU по нынешним меркам дрова полнейшие, так же как и пропуская способность ОЗУ. Честно сказать, я ожидал слайдшоу везде и невозможность пользоваться интернетом в актуальной версии браузера. Но ноутбук 2008-го года выпуска всё еще пригоден для современной ОС и современного веба.

Обвес машинки такой, что на боковых стенках почти нет пустого места: https://www.notebook-center.ru/catalog_acer_1684.html. Теперь так не делают. (На самом деле делают, но где-то 1 модель из сотни.)

1. Релизная модель и версионирование.

Релизная модель: стабильные релизы с опциональными обновлениями.

Номер версии можно представить в следующем виде: YYYY.SU.R, где:

• YYYY - номер мажорного выпуска дистрибутива. Формируется по году выпуска дистрибутива. В рамках мажорного выпуска фиксированы ключевые особенности дистрибутива, такие как поддерживаемый пакетным менеджером набор фич (формат пакетов).
• SU — номер system update. В рамках одного номера system update фиксированы минорные версии библиотек и других системообразующих компонент. При переходе на следующий system update минорные версии могут меняться с сохранением обратной совместимости ABI.
• R - номер корректирующего выпуска с исправлениями багов и закрытием уязвимостей.

В применениях, где требуется максимальное сохранение стабильности ABI, следует использовать выбранную ветку YYYY.SU и не переключаться на другие SU.

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

Как отдельные ветки SU, так и мажорный выпуск YYYY в целом, поддерживаются до тех пор, пока есть энтузиасты, готовые заниматься сопровождением. Понятие «перевода дистрибутива в архив» не существует. Любая сколь угодно старая ветка может получить корректирующие апдейты или новые SU при условии, что есть желающие сформировать апдейт, он соответствует критериям качества, а также есть ответственные лица, которые могут провести оценку по этим критериям.

2. Система сборки и пакетирования.

Для пакетирования применяется система, подобная Arch/Alpine/Void: то есть дерево портов со сборочными рецептами на shell. Однако процедура сборки более формализована.

Существует три уровня организации рецептов сборки.

На первом уровне хранятся сборочные рецепты для пакетов в наиболее общем виде.

На втором уровне они детализуются различными опциями сборки. Например, из одного исходного пакета может собираться несколько вариантов программы под разные тулкиты, с разными включенными флагами сборки и т.п.

На третьем уровне сборочные зависимости точно специфицируются в привязке к состоянию репозитория собранных пакетов конкретной ветки дистрибутива. Это позволяет при необходимости повторить сборку пакета в идентичных условиях с абсолютно идентичными зависимостями.

После полной спецификации сборочного рецепта, он поступает на обработку сборочной фермой, которая воспроизводит указанное состояние сборочной среды и собирает пакет. Для сборки пакетов пользователем локально должна быть предоставлена точно такая же возможность из коробки, не требующая дополнительных усилий по настройке. Сборка пакетов в формально специфицированной изолированной среде должна быть режимом по умолчанию, а не опцией, требующей отдельного конфигурирования.

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

Для ран-тайм зависимостей используется указание, максимально приближенное к «реальному состоянию дел». Например, если приложение динамически слинковано с libjpeg.so.8, значит именно libjpeg.so.8 будет указан в зависимостях пакета. А если точнее, то в качестве зависимости указывается PLATFORM:libjpeg.so.8, где PLATFORM - один из вариантов платформы, поддерживаемой дистрибутивом (ближайший аналог спецификатора multiarch в Debian).

Также ран-тайм зависимости более точно указывают на конкретные версии интерпретаторов и сред исполнения. Например, возможно бесконфликтное существование нескольких веток python 3.x с отдельными наборами библиотек.

3. multiarch и multiOS

В дистрибутиве возможно параллельное существование нескольких вариантов /usr/lib под разные ABI, подобно тому, как это реализовано в Debian. Кроме того, этот подход может быть расширен для поддержки разных ядер операционных систем за пределами Linux, таких как NetBSD или сборка пакетов для cygwin-подобного ран-тайма под WinAPI.

4. portable-сборки и развертывание пакетов без админского доступа.

В метаинформацию пакета включена информация о том, может ли он быть установлен и использоваться по произвольным путям или же привязан к конкретным путям.

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

Также возможна автоматическая конвертация portable-пакетов в пакеты системы Zero Install, что позволяет устанавливать их на любой мейстримной Linux-based ОС.

5. Декларативная конфигурация системы

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

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

Например, в Arch сейчас всего менее 400 пакетов имеют install-скрипт. Это полная противоположность скриптового хаоса в Debian-based дистрибутивах, где это количество измеряется тысячами. Из этого количества в 400 штук - около половины просто выводит сообщение пользователю. Из оставшихся больше половины вызывают команды типа setcap/chmod/chown для конфигурирования прав доступа и привилегий для пакета. Все эти действия могут быть заданы декларативно. Еще часть пакетов содержит избыточные команды, которые и так обрабатываются хуками ПМ.

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

6. Отсутствие неявной «автоматической» конфигурации системы

Пакетный менеджер ставит пакеты. Он не запускает демоны, не настраивает конфиги в /etc, не правит симлинки. Он устанавливает и удаляет пакеты предсказуемым образом с целью сохранения воспроизводимого состояния системы.

Также это подразумевает отсутствие какого-либо --install-recommends. Ставятся только жесткие зависимости пакетов, и они же удаляются при рекурсивном удалении. Управление дополнительными компонентами может выполняться пользователем самостоятельно.

С целью более удобного управления пакетами, в ПМ должна быть предусмотрена возможность для пользователя оставлять и просматривать локальные комментарии для пакетов. Чтобы пользователь мог написать для пакета заметку вида:

# apt comment 'libblabla-git' 'Установил версию прямо из github как makedep для progfoobarbaz'

7. Политика сборки пакетов.

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

Энтузиасты, однако, могут поддерживать кастомные варианты пакетов с патчами, меняющими настройки и функциональность программ. Суть таких пакетов должна быть явно видна из их названия и описания. Например: linux - ядро Linux; linux-zen - ядро Linux, собранное с патч-сетом zen.

8. Особые возможности дистрибутива

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

• Вынос логики nsswitch в отдельный системный демон. glibc больше не занимается ничем, что связано с nsswitch. Она просто коннектится к демону и запрашивает у него необходимую информацию. Аналогичная поддержка должна быть также внедрена в musl. Статические программы теперь могут быть действительно статическими. А логика работы nsswitch изолирована за платформенно-независимым протоколом и отвязана от ABI прикладного кода.

(Пока только один пункт)

9. systemd или openrc, glibc или musl

Ответ: и то, и другое, при наличии энтузиастов, готовых поддерживать соответствующие ветки дистрибутива. Однако если кто-то делает ветку без systemd, значит отказ от systemd должен быть полным. Никаких костылей в виде elogind. Только ConsoleKit2 вместо него. Кроме того, использование средств, отличных от systemd, не должно вредить возможностям декларативной конфигурации системы.

Забавная всё-таки штука.

Установлена у меня на флешке в виде микса из Arch и Debian Bookworm.

От дебиана установлена базовая система с XFCE. От Арча - весь остальной софт: браузеры, офисные пакеты и т.п.

По сути же это две отдельные ОС, загрузиться можно в любую. Но бинарники в PATH, desktop-файлы и часть конфигов в /etc у них общие благодаря магии Bedrock. Таким образом в обоих системах доступен софт из любой из них.

Хотел просто обновить на флешке Арч, но увлёкся и теперь обновляю Debian. Debian я ставил в прошлом году - по сути тестинг, но прописал сразу пути репозиториев для bookworm, чтобы она дальше этого релиза в тестинг не укатила.

Жду вот сейчас, пока он XFCE с 4.16 на 4.18 обновляет. Со слабой надеждой, что там я увижу что-нибудь интересное. Потому что XFCE на самом деле мне не нравится.

Концепция этого микса намекает иметь стабильную платформу от Дебиана и свежий софт от Арча. И значит под дебианом нужна какая-то стабильная DE. Я бы лучше KDE5 поставил. Но они крупноваты для флешки. А других реальных альтернатив вроде и нет. LXQt сырая, MATE - не лучше XFCE, корица тащит куски гнома.

Есть какая-нибудь настройка, чтобы заставить apt выводить списки пакетов (когда он пишет «Следующие пакеты будут удалены/обновлены/etc:») в виде столбца по одному пакету на строку, а не этой простынкой по дефолту? Ну читать же невозможно такой список.

xrandr сообщает верные значения физического размера экрана:

$ xrandr | grep mm
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 380mm x 210mm

А здесь значения неверные:

$ xdpyinfo | grep dimen -A1
  dimensions:    1920x1080 pixels (508x285 millimeters)
  resolution:    96x96 dots per inch

https://ibb.co/5LKBqC1

Что это за ерунда и какой пункт правил нарушен?

Хотел зарегаться на archlinux.org.ru - не приходит письмо.

Потом вспомнил, что раньше уже вроде был акк, поискал по почтам - нашел. Хотел сделать восстановление пароля - тоже не приходит письмо.

Не увидел нигде емайла для связи с администрацией. Может кто знает?

Ну или если есть рега на форуме, то спросите там, рассылку емайлов для регистрации они починят?

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

В общем, я создал профиль организации и начал помаленьку мерджить старые пулл-реквесты: https://github.com/lxde-continued

Кто хочет присоединиться к этому занятию, пишите, добавлю.

С прежними разрабами LXDE каши не сваришь.

https://github.com/lxde-continued/lxde-continued/issues/1

https://github.com/orgs/lxde-continued/discussions/2

https://github.com/orgs/lxde-continued/discussions/4

Сабж на картинке: https://ibb.co/VQXPrRx

Я себе весь мозг сломал.

Позиция разработчика в прошлом году:

The final release of tint2 is 17.0.2.

The code is frozen and no more feature requests are accepted.

Неделю назад ему там коммент оставили:

Recent code changes in tint2 dependencies arise issues that are relevant.

Is there any possibilities that the support for tint2 will be resumed at least to fix such problems?

Собственно вопрос. Если ли где новый живой апстрим, готовый делать релизы. Может видел кто…