https://lwn.net/Articles/871195/

Вообще, жить близко к транку - это хорошая идея. Но не в случае ядра.

Любое свежеизготовленное ядро - это, извините, кусок говна. Вы видели процессы разработки ядра линукс? Вы знаете, как оно тестируется?

Обычно разработчики ядра говорят, что тестировать ядро можно только наживую. Это, конечно, не так. Где, скажем, юниттесты на базовые контейнеры и примитивы синхронизации? Где фаззитесты на файловые системы? FS, вообще говоря, элементарно мокается посредством мока блочного устройства, и не менее элементарно фаззится. Где покоммитные тесты на стабильность ABI? Я знаю только про существование интеграционных тестов(когда ядро целиком запускается в чем-то типа qemu, но в живую их не видел).

Мое текущее понимание модели разработки ядра - что за FS отвечает мейнтейнер этой FS, который принимает в нее патчи, и мержит их в mainline. У кажого мейнтейнера свои подходы к тестированию, и они далеки от идеальных. Кто отвечает за то, что изменения в mmu не поломают какое-то изменение в FS, я не понимаю. Это явно не мейнтейнер MMU, и явно не мейнтейнер FS. По моему, Linus, то есть, никто.

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

Поэтому что там собирается ловить Гугл, для "a near-mainline kernel for development and testing", я не очень понимаю. Ну, то есть, я совершенно понимаю задачу "сократить число патчей с 9000 до 2000", совершенно понятный ход "выкладывать смерженные ядра на 1000 хостов по мере готовности, а не раз в 2 года". Но вот как они будут отделять баги своих патчей от багов свежеиспеченного ядра - вопрос открытый. Хотя это, в любом случае, улучшит качество свежеиспеченных версий ядра, что хорошо для индустрии. По крайней мере, тестов Гугл на ядро наваяет.

https://blog.cloudflare.com/branch-predictor/

Хороший пост про branch predictor.

Long story short(с заметными упрощениями!):

// branch
if (x) {
    // not taken
} else {
    // taken
}

Branch Predictor = HashMap<Instruction Pointer, N="10011100">, где N - паттерн taken/not taken для последних прыжков по этому IP.

Размер этой таблицы - несколько тысяч элементов(зависит от архитектуры, и от того, что предсказываем(jmp/call))

Можно считать, что not taken branch не стоит почти ничего(кроме паталогических случаев, когда все плотненько забито jmp).

Если не играть с likely/unlikely, код лучше оформлять так(это напрямую не следует из статьи, так говорит опыт):

if (x) {
    // hot code

    if (y) {
        // hot code
    } else {
        // cold code
    }
} else {
    // cold code
}

Паттерн

if (error) {
    return error;
}

// hot code

не самый лучший, потому что бранч будет чаще taken.

Важно смотреть ассемблер, чтобы понимать, что компилятор правильно понял про ветки if, taken они, или нет.

В компиляторах есть атрибуты hot, cold, ими можно размечать код.

Одной строкой:

* до чего довел планету этот фигляр ПЖГвидо.

https://brmmm3.github.io/posts/2019/07/28/python_and_lua/
https://github.com/scoder/lupa

Люди делают offload cpu intensive нагрузки из Питона в Lua, потому что:
- lua параллелится
- lua имеет jit, и в разы быстрее per core.

В Lua, Карл! Даже не в С!

* На просторах интернетов нашел блог создателя musl. Мне зашли два поста:

http://ewontfix.com/18/. Читаем ассемблерные листинги, больше никогда не смотрим в сторону .so
http://ewontfix.com/17/. Legacy в Linux. В Linux треды это процессы, поэтому uid/gid там, на самом деле, пертредные. Рассказ про то, как сложно сделать атомарное изменение setuid для пачки тредов одного процесса(которые, на самом деле, тоже процессы).

* Красивое про musl и #glibc. Сам баг не очень интересен, а вот разница подходов к разработке очень даже.

https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html

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

https://wiki.musl-libc.org/faq.html

Ждем libc от LLVM! https://llvm.org/docs/Proposals/LLVMLibC.html

https://www.tiobe.com/tiobe-index/ - python-то ого-го! Правда, дельта примерно 0, прост остальные упали.

Недавно наткнулся на ошибку valgrind в библиотеке RE2, if по неинициализированной памяти. Не думая, влепил туда memset, и зря, потому что это был единственный известный мне случай использования if по неинициализированной памяти во благо:

https://titanwolf.org/Network/Articles/Article?AID=a9a4c148-1643-4a82-aac1-a58ebef5d7c3#gsc.tab=0

Кстати:

1) RE2 лучшая библиотека регулярок для C++
2) Цикл про регулярки и про code search от автора RE2, Russ Cox, https://swtch.com/~rsc/regexp/ - это нужно знать всем.
3) Про переписывание компилятора Go с C на Go, от него же. https://www.youtube.com/watch?v=QIE5nV5fDwA Go я не люблю(там нет нормальной обработки ошибок и дженериков), но видос зажигательный.

* https://lists.llvm.org/pipermail/llvm-dev/2021-October/153113.html

LLVM хочет отказаться от фабрикатора, в пользу github PR's(не потому что он плохой, а потому что его забросили). Печаль. Мне гораздо более симпатичны(и удобны) тулзы, которые делают программисты для программистов(хотя они и вырвиглазны), чем те, которые делают дизайнеры для программистов.

* #glibc теперь можно не только собрать c clang, но и слинковать с lld. Вы уже знаете мою любовь к инструментам от GNU, поэтому новость позитивная, конечно. https://www.collabora.com/news-and-blog/blog/2021/09/30/a-tale-of-two-toolchains-and-glibc/

* пост за paywall, https://lwn.net/Articles/871866/ Про реализацию SMB протокола в ядре. #ksmbd Мои 5 копеек:
- судьба #khttpd ничему людей не научила
- нормальные люди из ядра пытаются что-то вынести, а не добавить. Сотни миллионов строк кода в ring 0 - это ненормально.
- почему не попробовали сделать то же самое, но в user space, с помощью #io_uring? io_uring нивелирует стоимость системных вызовов, и чем больше нагрузка, тем меньше получаются расходы на системные вызовы.

* умер Jörg Schilling https://lwn.net/Articles/872489/. Если бы не этот плачевный факт, он бы обязательно попал бы к нам в коллекцию упоротых(в хорошем смысле этого слова) людей. Посудите сами - своя система сборки smake, свой дистрибутив Solaris, так же он автор cdrtools(школота уже не помнит, но мы-то помним, как резали ими компакт-диски под linux). Мы такое любим. :(

#terminal

У нас тут проходил опрос на тему "какой эмулятор терминала вы используете". Я был очень удивлен, увидев, что #Alacritty там занимает предпоследнее место. Давайте я вам расскажу за эмуляторы терминала.

Исхожу я из следующих положений:

1) Благодаря встроенным в эмулятор настройкам, или используя что-то типа Karabiner Elements, keybindings можно настроить произвольным образом. Ну, то есть, можно отобразить любую комбинацию клавиш в любую последовательность ESC codes. Это упражнение можно проделать для любого известного мне эмулятора терминала. Например, я как 20 лет назад привык к keybindings от Konsole, так и использую их везде, хотя предпочтительный эмулятор терминала у меня менялся раза 4.

2) Благодаря tmux и подобным программам можно получить одинаковый(ну, почти одинаковый) user experience в любом эмуляторе терминала. Неудобство управления tmux(все вот эти C-b x) решаются с помощью пункта 1.

Какие у нас остаются различия?

1) Рендеринг шрифтов. Я имею наглость утверждать, что, если вы используете для терминала какой-то "внесистемный" рендеринг шрифтов(например, FreeType под macOS), то вы что-то делаете не так, и вам стоит поменять OS, чтобы не мучить глаза. Если вы используете системный рендеринг шрифтов в эмуляторе терминала, то вам пофиг на то, как называется программа, которая дергает системные функции.

2) Скорость отрисовки. Тут все очень просто, эту метрику можно объективно посчитать. Я инструментировал свой текстовый редактор, чтобы он умел работать с текстом в batch режиме(даем программе текстовый файл, последовательность команд, смотрим, сколько времени они выполняются). На первом месте по этой метрике получается Alacritty, остальные терминалы довольно далеко позади(iTerm, Kitty, Hyper.js, встроенный в macOS).

3) Мерцание. Это совсем не то же самое, что и 2. К сожалению, большинство терминалов написаны совсем рукожопно, поэтому они легко могут читать команды от приложения в буфер фиксированной длины, и когда буфер заканчивается, делать flush изменений прямо на экран. Это совершенно неверная модель, потому что мы легко можем сделать flush в середине отрисовки экрана приложением. По этой метрике все терминалы, за исключением одного, ведут себя довольно плохо. Единственный терминал, который я не смог уличить в мерцании, это Hyper.js(очень неплохой терминал, кстати, к сожалению, его разработку практически забросили(я знаю, что у него был релиз в первый раз за 2 года несколько дней назад, релиз "забагован" по самое не хочу)).

Короче, к чему это я? Мне кажется, что из вышеизложенного текста получается, что почти всегда сейчас нужно пользоваться Alacritty(за исключением того случая, когда для вас очень важно мерцание, тогда можно посмотреть на Hyper.js)

Раз уж начал про эмуляторы терминала, расскажу еще одну интересную вещь.

Изменение размеров окна в них сделано не посылкой in order команды программе внутри терминала, а с помощью посылки асинхронного out of order сигнала SIGWINCH(по примему которого программа должна in order спросить у эмулятора терминала новые размеры окна). Ни один известный мне эмулятор терминала не реализует этот протокол корректно - при изменении размеров окна всегда будут случаи некорректной отрисовки приложения. Правильный протокол выглядит так: когда эмулятор терминала понимает, что окно изменило размер:

1) Нужно послать SIGWINCH приложению(out of order)
2) Нужно дождаться, когда приложение пришлет запрос на определение новых размеров(in order). Послать ему ответ.
3) Вот тут тонкий момент. Так как у нас нет нормального framing и подтверждений о доставке, нужно дождаться, когда буфер в pipe становится пустым, в обе стороны. Это не всегда возможно(например, если прямо сейчас в терминале запущен cat на большой файл), поэтому эту операцию нужно делать с timeout.
4) Только в этот момент можно поменять в своих структурах данных размерности окна на новые. Если это сделать раньше, возможны глюки.

К сожалению, что эмуляторы терминала, что программы, тут предпочитают логику на sleep.

https://www.opennet.ru/opennews/art.shtml?num=55956

Тут должна быть шутка про JS разработчиков, или про Memory Safety в Rust, но мне немного лень.

Например, 2 разных подхода к оценке реализации асинхронности(вторая ссылка не про C++, но она точно так же применима к С++, или к Python):

https://habr.com/ru/company/yandex/blog/575062/
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ (названия каждой новой главы доставляет)

Или, например, как сдизайнен async API в jinja2:
https://jinja.palletsprojects.com/en/3.0.x/api/

Казалось бы, где jinja2, и где async? Но нет, мы же можем передать в нее контекст, который загружает шаблоны по сети.

Я, скорее, согласен со вторым автором. Пока будет такое разделение на 2 мира, и поддержку async придется добавлять руками, дублируя код, async популярным не станет.

Кстати, зачем Python ушел от yield from к async/await - я не понимаю. По сути, как раз в Python не было(вернее, она была еще раньше - обычные функции vs. генераторы, но никогда не было проблем звать функции из одного мира в другом) этой проблемы разделения на 2 мира, и ее добавили искуственно.

PS: как сделать call/cc(очень похожая на корутины тема) в С++, с помощью fork() http://mainisusuallyafunction.blogspot.com/2012/02/continuations-in-c-with-fork.html Осторожно, по ночам будут кошмары.

Оказывается, G уже запилила fuzzer для Linux:
https://github.com/google/syzkaller

С внушительным послужным списком:
https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs.md

Это прекрасно. Интересно, используется ли это в процессах разработки ядра, или работает сбоку?

Фаззить системные вызовы - это хорошо, но мало.

Мне нравится использовать контейнеры, но я не люблю docker.

Нужно понимать, что docker - это не то, что реально выполняет код в контейнере. Это очень простой CLI над несколькими системами Linux. Фактически, задача docker - скачать tar.gz с файлами образа, и запустить какой-то OCI compatible runtime над разархивированной папочкой. Docker - самый старый такой CLI для Linux(если не вспоминать LXC). Поэтому он накопил довольно большой груз проблем.

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

Например, процессы контейнера запускаются этим демоном. Лично меня беспокоит соседство внешнего кода и root демона. Я понимаю, что демон сбрасывает привилегии, но когда это кому мешало? Код может сбежать из контейнера, и наличие некоего демона, который обеспечивает какие-то важные функции для этого контейнера(то есть, обрабатывает запросы от него!), и работает под root - ну такое.

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

Поэтому docker'у я предпочитаю daemonless, rootless решения:

1) Podman. Работает daemonless, умеет работать rootless. Обеспечивает CLI такой же, как у docker. А теперь и под macOS! https://davegallant.ca/blog/2021/10/11/replacing-docker-with-podman-on-macos-and-linux/

2) Семейство udocker. https://github.com/indigo-dc/udocker. Вообще не требует ничего от системы, даже USER_NS. Работает с помощью тулзы под названием proot(https://proot-me.github.io/), которая перехватывает системные вызовы от управляемого процесса с помощью ptrace(считайте, API для отладчика). Написан на python, что для меня глоток свежего воздуха, после засилья Go во всяких CLI для контейнеризации.

3) Таки звать OCI runtime напрямую! Это не rocket science - скачать tgz, распаковать ее, и запустить 1 бинарь:

pg@:~/bundle mkdir rootfs
pg@:~/bundle docker export $(docker create busybox) | tar -C rootfs -xvf - > /dev/null # тут можно позвать curl
pg@:~/bundle runc spec --rootless # создаем config.json, почитайте его, там тоже никакой магии
pg@:~/bundle runc --root /tmp/runc run qw
/ #

Actually, это мой любимый способ. Такой chroot на стероидах, со всеми вытекающими удобствами. Во первых, он совершенно не оставляет за собой "следов" в виде висящих процессов, во вторых, очень гибкий(например, попробуйте под docker build заменить содержимое /etc/hosts - https://stackoverflow.com/questions/38302867/how-to-update-etc-hosts-file-in-docker-image-during-docker-build, и не работает для ipv6), это важно для всяких CI/CD pipeline.

Вместо runc(это OCI runtime от docker) можно взять любой другой - https://github.com/containers/crun, тысячи их!

И вторая важная тема!

Контейнеры под Linux - это не способ изоляции! Контейнеры имеют полный доступ к ядру Linux, и могут произвольно эксплуатировать уязвимости в нем! Поэтому, желательно, использовать какую-то прослойку между ядром Linux, и пользовательским кодом контейнера. Например, для этой цели можно ипользовать gVisor. https://github.com/google/gvisor Это такой эмулятор ядра Linux, написанный поверх ядра Linux. У него есть некоторые недостатки:

* Написан на Go, И требует bazel для сборки - это аццкое сочетание, trust me.
* Пока не умеет в rootless :(

Если приходится использовать docker безальтернативно, я крайне рекомендую посмотреть на gvisor, для более лучшей изоляции.

Интересных ссылок в последние дни нет.

Разве что:

* Новая Зеландия отменила контракт со штатным колдуном. https://boingboing.net/2021/10/13/official-city-wizard-fired-from-new-zealand-city-after-over-20-years-of-public-service.html Оригинальная ссылка недоступна, возможно, происки колдуна.

* Вышла совершенно ничем не примечательная OpenBSD 7.0 Ссылку на changelog не кидаю, там ничего нет. Зато, как обычно, с каждым новым релизом OpenBSD разработчики выкладывают какую-то графоманскую мелодию, которой можно насладиться тут - https://www.openbsd.org/lyrics.html#70 Треш, угар, содомия.

* Российская Государственная Открытая Лицензия - https://habr.com/ru/news/t/583156/ Сейчас запилят православный github, тогда заживем.

* Переписка про удаление GIL из Python - https://mail.python.org/archives/list/python-dev@python.org/thread/ABR2L6BENNA6UPSPKV474HCS4LWT26GY/

Вот что пишет г-н Гвидо про nogil: #gil #fast_python

"To be clear, Sam’s basic approach is a bit slower for single-threaded code, and he admits that. But to sweeten the pot he has also applied a bunch of unrelated speedups that make it faster in general, so that overall it’s always a win. But presumably we could upstream the latter easily, separately from the GIL-freeing part."

"Я с удовольствием использую идеи автора в своем проекте по ускорению Python"

Осталось понять, PRO, или MAX?

Заявления Apple про скорость звучат, как чудо, но M1 они же доставили?

https://www.apple.com/ru/shop/buy-mac/macbook-pro/14-%D0%B4%D1%8E%D0%B9%D0%BC%D0%BE%D0%B2

https://news.ycombinator.com/item?id=28908383 - 1800 коментов, давненько на HN такого не видел.

Очень мне нравится новый экран. 2560x мне было маловато(например, после Asus ROG Flow X13 с его 3840x). Я вижу отдельные пиксели в шрифтах :( Интересно, почему в этой области Apple не пытается быть впереди планеты всей?

Свои процессоры сегодня не делает только ленивый!

https://www.ixbt.com/news/2021/10/19/128-ddr5-pcie-5-5-alibaba.html

В догонку - хороший текст на хабре про стоимость процессоростроения, между прочим, от автора epic battle Ядра vs. Elbrus! https://habr.com/ru/post/583780/

Доразбирал прошлый дайджест llvmweekly.org

1) Неплохая заметка про то, как работает линкер - https://blog.llvm.org/posts/2021-10-01-generating-relocatable-code-for-arm-processors/

Первая половина - годное введение в проблему(например, становится понятно, почему способ линковки зависит от конечной системы).

Вторая половина - на мой взгляд, какое-то очень невнятное решение понятной проблемы, которую линкеры уже давно умеют решать(relocatable static binary, c 2 секциями - .text, .data). Так же авторы, IMHO, периодически сваливаются с темы "relocatable" на тему "position independant". pi code является relocatable, но не наоборот, и делать его сложнее.

2) А кто-нибудь понимает, зачем LLVM продолжает пилить свою libc? https://reviews.llvm.org/rGdb8a88fef87e

3) Мы же теперь живем в мире, где участие женщин в IT надо как-то специально, не на общих основаниях, подсвечивать, да? Вот, llvmweekly дает ссылку на "Women in Compilers and Tools meetup" - https://www.youtube.com/watch?v=1-H8RTwCpwA Я тоже даю, я хороший. Cлушать там не о чем.

https://lwn.net/ml/linux-next/20211008113116.4bdd7b6c@canb.auug.org.au/

Например, история, как посрались 2 мейнтенера ядра Linux - разработчик драйвера AMD GPU Simon Ser, и Christoph Hellwig. Второй удалил из интерфейса ядра для модулей функцию, которую использовал первый.

Тут, конечно, есть вопрос того, можно ли из модуля спрашивать у ядра, какой процесс нас сейчас зовет, или нет, но это вопрос отдельный. А вот важный вопрос - на каком этапе разработки должен был случиться этот конфликт. Мой ответ - как можно раньше, и об этом должна была сообщить CI система, проверяющая сборку ядра.

Но kernel hackers такие kernel hackers.

PS: посрались знатно, практически с матюгами, и жалобами маме Линусу.

Написал тут AGPL в поиске в русской расскладке, и понял, что пора бы уже написать, почему я не люблю GNU/FSF/GPL.

#GPL

Если совсем коротко:

1) Слух о их полезности для дела бутстрапа OSS "несколько" преувеличен
2) Сейчас они индустрии больше вредят, чем помогают
3) С этической точки зрения они сильно похожи на движение SJW(которое я искренне ненавижу)

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

Поехали, часть первая!

Есть такой тулчейн, под названием LLVM. В него входит дебаггер LLDB, основной конкурент GDB. Я тут, на днях, собирал его для своего дистрибутива MIX, и нарвался на красивое.

Есть такая библиотека - readline. https://tiswww.case.edu/php/chet/readline/rltop.html Она распространяется по лицензии GPL3 (даже не LGPL!). Библиотека решает очень простую задачу - позволяет делать удобный пользовательский ввод, с редактированием, и историей. Понятно, что эта библиотека используется в куче софта - bash, python, gdb, везде, где нужен пользовательский ввод. К сожалению, лицензия библиотеки не позволяет ее использовать в бОльшей части OSS софта, из-за лицензии. Поэтому проект BSD запилил свою реализацию API readline - libedit. http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date#dirlist Реализация, как обычно в мире OSS, неполная, но более-менее работает.

В чем прикол?

1) LLDB содержит в себе интерпретатор питона, для расширения
2) LLDB, как настоящее свободное программное обеспечение, использует libedit
3) Python под Linux настаивает(ну, до недавнего времени) на readline.

Это выливается в ошибки линковки, а если их "починить", то в падения в runtime - несмотря на то, что функции в libedit называются так же, как в readline, структуры данных имеют разный layout.

Очевидное решение - собирать python с libedit для LLDB. Ага, щас, вот феерический тикет про интеграцию libedit в python - https://bugs.python.org/issue13501

long story short - собрать python с libedit стало возможным совсем недавно, заняло это несколько ЛЕТ согласований.

"LLDB is a bit of a special case: LLDB links against libedit, but the Python libedit module is built as if readline is in use. It turns out this "magically" works out, presumably due to the runtime workaround detection. As far as I know this issue would affect Linux as well, but perhaps the version of libedit on common Linux distributions is one with the 0-based vs 1-based history fix?"

Почему так? Потому что какие-то долбоебы решили, что нижележащая инфраструктурная библиотека в Linux должна идти под copyleft лицензией. Извините, но инфраструктурная библиотека под GPL - это леденящий душу п№%дец. Это привело к фрагментации OSS мира, и к потере огромного количества человеко-лет. Что получила GNU/FSF от этого, кроме чувства огромного морального удовлетворения? Ничего. Libedit успешно существует, собака лает, караван идет. Страдают пользователи, исключительно из-за политики FSF.

Причем за развитие libedit "платят" пользователи OSS, те самые, о благе которых, якобы, беспокоится FSF, а не корпорации, от которых нас FSF "защищает". "платят", потому что ресурсы на эту мышиную возню можно было потратить иначе.

Перечитал текст, и задумался - а имеет ли вообще модуль readline в Python право на существование? Очевидно, сам модуль должен быть под GPL3, раз он линкуется с libreadline. При этом, интерпретатор питона загружает его в runtime. Какой, в итоге, должна быть лицензия конечного продукта? Имеет ли право не-gpl программа загружать gpl .so в runtime?

Таким вопросом задавался не только я:

https://python-list.python.narkive.com/ZktLTSUV/gnu-readline-licensing
https://www.b-list.org/weblog/2009/jul/14/licensing/ - очень интересная тема про то, как могут в одном питоне жить ssl и readline(раньше openssl была несовместима с GPL). А если учесть, что REPL Питона принудительно загружает модуль readline...
https://yarchive.net/comp/linux/gpl_modules.html (про загрузку проприетарных модулей ядра в Linux)

Напишу-ка я в FSF.

Например, блог разработчиков RedHat, с описанием того чудесного мира, куда RedHat собирается тащить десктопный Linux:

https://blogs.gnome.org/uraeus/2021/09/24/fedora-workstation-our-vision-for-linux-desktop/

Что я могу сказать? Я могу сказать, что RedHat тщательно игнорирует тренды современных языков, которые, по умолчанию, делают статическую линковку(Go, Zig, Rust, Swift, etc), навязывая дурацкий FlatPak(https://flatpak.org/) для дистрибуции приложений для Linux. К счастью, ничего они с этими трендами сделать не cмогут, и FlatPak будет постепенно умирать с остатками кода на С/С++. Может быть, трансформируется во что-то более удобное, типа бандлов в MacOS, для более удобного доступа к ресурсам приложения.

PS: flatpak, конечно, строго лучше того dll hell, что есть во всех мажорных дистрибутивах Linux, но "будущее" - вряд ли.

Новости из мира GNU. SFC подала иск за нарушение GPL на компанию #Vizio. https://lwn.net/Articles/873338/

Я прочитал публичную часть иска - https://shoestring.agency/wp-content/uploads/2021/10/SFC_PressKit_10-19-2021_v1.pdf

Все в лучших традициях GNU/FSF:

1) 20 страниц самореламы, без конкретных претензий к компании
2) Передергивания на передергивании. Just to name a few:
"… that you, as the consumer, have specific rights to modify, improve, repair and fix the software in your Linux-based products?"

Вот, из моего третьего пункта следует, что они настаивают на моем праве пофиксить bash в телевизоре. Но вот из их текста кажется, что я имею право лезть в саму прошивку Vizio.

"Vizio has a long history of violating copyleft, furthermore:
Vizio has already been subject to a large class-action suit that alleged that Vizio was misusing its customers’ private information"

Дооо, из того, что на Vizio уже подавали за что-то в суд, следует, что она нарушает copyleft.

3) Actually, на 20 страницах ровно 1 строчка претензий по существу. Что мы из нее узнаем?

"Smartcast is a Linux-based operating system. That means that not only do multiple copies of the Linux kernel appear in the firmware, other GPL’d and LGPL’d programs were found, including U-Boot, bash, gawk, tar, glibc, and ffmpeg."

Вы понимаете, к чему прикопалась эта пиявка? К тому, что в телевизоре есть bash && ffmpeg. bash/ffmpeg/прочее из этого списка, позволю себе напомнить, не идет под AGPL, поэтому требовать на этой основе открытия исходников софта Vizio под GPL нельзя. Можно требовать открытия патчей на bash, но если патчей нет, то и требовать нечего. Есть ли патчи на bash, или нет - иск стыдливо умалчивает.

4) Самая мякотка, которая показывает, насколько GPL защищает права пользователей на самом деле:

"that what makes this litigation unique and historic in terms of defending consumer rights is the fact that it is the first case that focuses on the rights of individual consumers as third-party beneficiaries of the #GPL. "

Сцуко, это ПЕРВЫЙ иск за всю историю #GPL, который подан не от лица разработчика! "Права пользователя на модификацию кода" my ass, ага.

GPL/FSF - это рак индустрии. Чем они вот отличаются от патентных троллей, с такими исками?