Привет, ЛОР!

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

#define SIZEOF_typename 4
#define ALIGNMENT_OF_typename 4
...

Запускать код при этом нельзя, потому что кросскомпиляция, смерть, жопа и сотона. Сейчас там это делается через автоконф (AC_CHECK_SIZEOF/ALIGNOF) и это не работает именно по этой причине. Что делать?

Про #define ALIGN_OF_X alignof(x) я в курсе, но проект древний и в нём есть вычисления через препроцессор, которые я пока не хочу трогать.

Привет, ЛОР!

Я хочу одну странную фичу: чтобы при однократном нажатии на Shift без других клавиш генерировалась левая или правая скобка для левого или правого шифта соответственно. Под иксами это делается простым запуском xcape -e 'Shift_L=parenleft;Shift_R=parenright'.

Пробовал через evremap, но он не позволяет отправить именно скобку на ввод. Только комбинацию, например, SHIFT+0, но её результат уже будет зависеть от раскладки.

Что посоветуешь?

UPD:

Анон подсказал рецепт с keyd.

Привет, ЛОР!

Три года назад один из разработчиков mpv выкатил пост с критикой Wayland, на который очень многие ссылались. В частности, там были описаны проблемы с рендерингом, не слишком корректный подход к проектированию и так далее.

Спустя три года, многое из этого изменилось, о чём и написано в новом посте. Так например, были добавлены протоколы для FIFO режима у Vulkan, поддержка в Mesa была допилена, некоторые другие проблемы тоже ушли. Всё это во многом стараниями корпораций Valve и Nvidia и нанятых ими разработчиков.

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

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

Такие дела, ЛОР.

P.S. пишу этот пост ради эксперимента из KDE+Wayland и хочу сказать, что синяя тема в HDR выглядит особенно мозгоразрывающе. За что мы конечно её ещё больше любим.

Привет, ЛОР!

В связи с ожесточёнными спорами вокруг внедрения языка Rust в ядро Linux, разработчик ядра Мигель Охеда (Miguel Ojeda) опубликовал список вопросов и ответов на них касательно сложившихся практик в разработке ядра и как это затрагивает Rust.

Тыц: https://rust-for-linux.com/rust-kernel-policy

В частности, следует отдельно упомянуть, что внедрение Rust поддерживается достаточно больших количеством разработчиков и мейнтейнеров ядра, включая таких людей как Greg Kroah-Hartman.

Привет, ЛОР!

Спустя три с лишним месяца после бана русских разработчиков из ядра, Linux Foundation наконец разразились постом в блоге, где они поясняют текущую ситуацию вокруг открытой разработки кода в проектах, базирующихся в США (как LF), имеющих разработчиков в США, либо принадлежащих компаниям из США.

Ссылка: https://www.linuxfoundation.org/blog/navigating-global-regulations-and-open-source-us-ofac-sanctions

Для Ъ:

• Санкции запрещают сотрудничество с людьми, находящимися под ними (/ К.О.), и любую работу в интересах этих людей;

• Санкции не разделяют коммерческую разработку и работу над открытыми проектами, и поэтому касаются фактически всех проектов. Т.е. если ты, ЛОРовец, имеешь друга в США и вы вместе запилили Hello World под GPL/MIT/BSD/WTFPL на гитхабе, твой друг нарушил эти санкции;

• Технически, если разработчик из России (или другой страны под санкциями) просто прислал патч, то его можно использовать. Однако, двухсторонняя переписка с этим разработчиком запрещена и его нельзя просить внести правки или каким-то другим образом с ним контактировать (см. пункт 3. Avoid Two-Way Engagement);

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

• С разработчиками под санкциями запрещено подписывать CLA или другие лицензионные соглашения;

• Запрещена непрямая работа с подсанкционными разработчиками. Т.е. если ты, ЛОРовец, попросишь своего друга Пьера из Франции передать за тебя патч в люникс, то такое принятие также будет рассматриваться как нарушение. В том числе это означает потенциальный запрет на совместную работу с анонимными разработчиками или разработчиками под псевдонимами. Пока, судя по всему, не очень понятны последствия этого, но потенциально может так сложиться, что для принятия патча в ядро потребуют скан паспорта.

Наш любимый блоггер Брайан Лундюк выпустил видео с разбором ситуации: https://youtube.com/watch?v=8sbJEH81gJ0

В общем, ЛОР, ситуация достаточно шизофреничная выходит. Enjoy!

Привет, @maxcom!

Не знаю, в какой момент это произошло, но в галерее больше не отображаются разрешение и размер запощенной картинки. Можно вернуть, плз?

Спасибо!

Привет, ЛОР!

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

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

Привет, ЛОР!

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

Исходники: https://codeberg.org/amjoseph/sixos

Презентация: https://media.ccc.de/v/38c3-sixos-a-nix-os-without-systemd

@mono, у меня нет виртуалов. Мы с @gaylord с одного VPN сидим =)

Разбанивай давай.

Привет, ЛОР!

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

Ссылка: https://www.edgedb.com/blog/c-stdlib-isn-t-threadsafe-and-even-safe-rust-didn-t-save-us

Для Ъ:

Функции getenv() и setenv() небезопасны в многопоточных программах. В частности, вызов setenv() во время выполнения getenv() в другом потоке может привести к порче памяти и падению программы. Это особенно релевантно на ARM64, потому как архитектура предоставляет меньше гарантий по части очерёдности выполнения команд.

И если бы это можно было списать на кривые руки авторов статьи, проблемы бы не было. Но тут суть в том, что огромное количество библиотек дёргают getenv() и setenv() под капотом с разными целями, в том числе гнутое gettext и прочие openssl.

Скажи, ЛОР, сишники совсем разучились писать безопасный код? Как с этим жить-то вообще?

UPD:

Подробный пост об этой проблеме: https://www.evanjones.ca/setenv-is-not-thread-safe.html

Прекрасное оттуда:

glibc uses an array to hold pointers to the "NAME=value" strings. It holds a lock in setenv() when changing this array, but not in getenv(). If a thread calling setenv() needs to resize the array of pointers, it copies the values to a new array and frees the previous one. This can cause other threads executing getenv() to crash, since they are now iterating deallocated memory.

То есть, вызов getenv() из glibc потенциально является use-after-free в многопоточной программе и от этого никак нельзя защититься.

Привет, ЛОР!

Тащемта, вопрос. В x86-16 были near и far pointers, что позволяло экономить на размере указателя в ту глубокую древность. Почему этот концепт не попал в 64-битные архитектуры? Ведь с учётом локальности, делать все указатели 64-битными выходит в конский расход памяти при том, что большая часть бит указателей в рамках одного экземпляра структуры данных (допустим, связанный список или дерево) будут одинаковыми. А значит, можно сэкономить кучу памяти, сохраняя только последние N бит указателя и хранить полный указатель, например, только в заголовке структуры данных.

В общем, вариантов как это может облегчить жизнь просто вагон. Почему этого сейчас нет нигде?

Update:

Вообще, такой подход дохрена где применяется. Гуглить «succinct data structures». Например, вот это: https://web.archive.org/web/20160312010342/https://www.computer.org/csdl/proceedings/focs/1989/1982/00/063533.pdf

Но мой вопрос скорее про то, почему этого нет на уровне языков/компиляторов.

Привет, ЛОР!

Вышла новая версия замечательного проекта OpenZFS, реализующего файловую систему ZFS. Изначально ZFS была разработана компанией Sun под названием Zettabyte File System (позже название было сокращено до просто ZFS) и поставлялась в ОС Solaris начиная с 2005 года. После покупки Sun корпорацией Oracle, исходники Solaris были закрыты. Проект OpenZFS был основан как форк последней открытой версии кода от Sun. Начиная с OpenZFS 2.0, он был объединён с наработками ZFS-on-Linux и в настоящее время поддерживает системы Linux и FreeBSD. Энтузиастами также развиваются порты для ОС Windows, macOS, Illumos и NetBSD.

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

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

Привет, ЛОР!

По мотивам этого, накопал скриншотов из 2007 с тогдашним свежесобранным E17 под Debian Etch. Нифига хорошего про эту среду не помню, помню что вернулся тогда очень быстро на KDE3 из-за общей глюкавости этого поделия. Повторять опыт не слишком хочу. E16 был и до сих пор есть куда лучше чем последующие версии. Единственным плюсом помню только полноценные анимированные обои без видео, которые не жрали при этом процессор как не в себя: в частности, вон та ленточка Debian на рабочем столе вращалась, и многим крышу сносило.

Такие дела.

Привет, ЛОР!

Как тебе известно, самая прогрессивная UNIX-система NetBSD до сих пор использует систему контроля версий CVS – факт, который многих в сообществе категорически не устраивает. Посему было решено перейти на более современную децентрализованную систему контроля. Проблема в том, что участники сообщества не смогли договориться о выборе и решили его попросту не делать.

Ссылка: https://mail-index.netbsd.org/tech-repository/2025/01/04/msg000805.html

Для Ъ: по ссылке план перехода. Сначала репозитарий CVS конвертируется в hg, а для фанатов git предлагается двухстороннее зеркало, синхронизируемое с помощью git-cinnabar.

Скажи, ЛОР, что ты думаешь по этому поводу? Может ли подобный подход работать в других проектах? Или стоит уже наконец отказаться от git и перейти на Mercurial?

Привет, ЛОР!

Плохие новости: Lenovo собираются выпустить новый Thinkpad без клитора. Помянем-с…

https://www.technetbooks.com/2024/12/lenovo-thinkpad-x9-ditches-iconic.html

Привет, ЛОР!

Вышла бета-версия достаточно интересного дистрибутива Chimera Linux. От других дистрибутивов Chimera отличается отсутствием утилит и библиотек GNU и использованием кода из систем BSD. Для сборки используются LLVM и musl с аллокатором mimalloc от Microsoft. В качестве системы инициализации поставляется Dinit. Средой рабочего стола по умолчанию является GNOME. Менеджером пакетов дистрибутива является APK (alpinelinux.org) (из Alpine Linux).

Chimera является бинарным дистрибутивом с готовыми сборками под архитектуры x86_64, ARM AArch64, POWER и RISC-V. Для энтузиастов также доступна сборка из исходного кода.

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

Привет, ЛОР!

А я почитал тред про Linux на PlayStation 2 в 2024. Чувак не сумел в установку ПО... я бы тоже не сумел. и решил добавить позитива в толксы.

Ссылка: https://luke8086.dev/netbsd-on-thinkpad-380z.html

Для Ъ:

Чувак поставил свежую NetBSD на Thinkpad 380Z (модель 1998 года, Pentium 2 233MHz, 160 мегабайт памяти) и… ВСЁ РАБОТАЕТ! Иксы стартуют, можно печатать в виме, работать по SSH, подключаться к удалённой сети через WireGuard, слушать музычку через mpg123 и так далее.

В общем, NetBSD может многое.

Разработчики NoSQL базы данных ScyllaDB решили прекратить публикацию кода под AGPL и с нового выпуска в 2025 году перейти на несвободную лицензию с открытым кодом (BSL).

Напомню, ScyllaDB является клоном базы данных Cassandra, переписанным на C++ (оригинал на Java) и имеющим гораздо более высокую производительность. В данный момент ScyllaDB имеет два варианта лицензирования: полностью свободная версия под AGPL и закрытая под проприетарной лицензией, обладающая расширенными возможностями для корпоративных пользователей. Начиная с версии 2025.1, ожидающейся в феврале будущего года, всё развитие будет сосредоточено на ScyllaDB Enterprise, которая станет доступна для бесплатного использования сообществом.

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

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

Привет, ЛОР!

Тихо и незаметно вышла новая версия великолепного компилятора языка Haskell. GHC развивается сообществом разработчиков с 1992 года и поддерживает компиляцию языка Haskell в нативный код как напрямую, так и с использованием инструментария LLVM.

Среди особенностей новой версии:

• Расширение языка OrPatterns, позволяющее давать общий обработчик нескольким веткам сравнения по образцу.
• Поддержка многострочных строковых литералов через специальный синтаксис: """строка""".
• В бэкенд компилятора добавлены экспериментальная поддержка архитектуры RISC-V и поддержка SIMD инструкций для архитектуры x86 (ранее требовалось использование LLVM).
• Удалена поддержка 32-битных версий ОС Windows, macOS и iOS. Поддержка 32-битных систем на базе Linux и BSD нетронута.
• Улучшена работа сборщика мусора. В некоторых случаях скорость работы программ может увеличиться на 25%.
• И множество других мелких фич, багфиксов и так далее.

>>> Скачать

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

Привет, ЛОР!

По старой традиции я вновь нарываюсь на бан^W^W^Wпрочитал для тебя свежий ежегодный отчёт Linux Foundation и принёс тебе интересного.

Ссылка на PDF: https://www.linuxfoundation.org/hubfs/Reports/2024%20Linux%20Foundation%20Annual%20Report_120524.pdf

Итак, ключевые пункты:

• PDF всё ещё верстается на маке (Adobe InDesign 20.0 (Macintosh)). Linux в LF использовать отказываются;
• Суммарный доход LF за прошедший год вырос до 292 миллионов долларов, расходы выросли до $299.7 миллионов;
• Из них, доля расхода на собственно ядро Linux в процентном соотношении упала до 2%, что в два раза меньше расходов на Blockchain (4%) и почти в 6 раз меньше расходов на ИИ, машинное обучение и подобные штуки (11%). Затраты на ядро Linux в LF в данный момент меньше, чем зарплата CEO Mozilla (предлагаю ввести это в качестве единицы измерения степени охреневшести впопенсорцных функционеров);
• Напомню, в связи с предыдущим пунктом, что из-за финансовых проблем с сопровождением срок поддержки LTS версии ядра сокращён с 5 до 2 лет;
• В этом году из отчёта напрочь исчезли такие термины как: diversity, inclusion, equity, climate change и другие интересные вещи. Я грепал, серьёзно. Наверное, что-то случилось;
• 70% членов совета директоров работают на корпорации, регулярно нарушающие GPL, в том числе и в отношение этого самого Linux. И двое работают в Microsoft.

В общем, такие дела, ЛОРовец. Также по традиции, призываю в тред @Shaman007 и @alpha, чтобы они мне объяснили как я капитально неправ и что на самом деле всё в порядке и так и должно быть.