Предлагаю создать Министерство Linux'а.

Минцифры планирует создать собственное Linux-сообщество для разработчиков из стран, готовых сотрудничать с Россией. Такое решение — реакция на отстранение российских разработчиков от мирового IT-сообщества
. . .
Панченко указал, что будет правильно, если новый форк Linux будет сделан сообществом стран, а не отдельной страной. «Это прибавит веса и авторитета. Но чтобы это сообщество заработало, России придется в нем быть лидером и донором программного кода и экспертизы в его разработке. Но есть важное препятствие — в России не так много разработчиков такого уровня, чтобы мы могли полностью взять на себя ответственность за ядро операционной системы. Поэтому важно срочно растить свои кадры», — рассуждает Панченко.
. . .
Идея Минцифры создать собственное Linux-сообщество выглядит слишком амбициозно, считает член совета директоров российского разработчика НТЦ ИТ РОСА и компании «Рутек» Сергей Кравцов. «Не стоит ожидать, что в официальной ветке Linux будут приняты изменения от российского сообщества. Основные решения относительно развития ядра Linux, по сути, будут оставаться международным сообществом, даже если Минцифры организует локальную команду разработчиков», — считает он.

Минцифры предложило создать собственное Linux-сообщество
https://www.rbc.ru/technology_and_media/28/10/2024/671e424c9a7947704249be2c

https://mitchellh.com/writing/ghostty-is-coming #ghostty #terminal

Тут вот коллега хочет запилить еще один "самый лучший" эмулятор терминала.

В тексте, конечно, есть (притянутое за уши) сравнение, которое объясняет нам, почему же ghostty будет лучше всех, но, на самом деле, это сравнение выглядит так:

          Zig
Alacritty -
Kitty     -
iTerm     -
Ghostty   X

Отдельно доставил пассаж про

"For "platform-native", Ghostty uses the native GUI toolkit on macOS and GTK (plus libadwaita if available) on Linux. This means that Ghostty looks and feels (and really is) a native application on both platforms. This is in contrast to many terminal emulators that use the native GUI toolkits only to create a window"

Вот что у этих людей творится в голове?

обычный вторник

https://www.rbc.ru/technology_and_media/29/10/2024/671fd2389a794726b01d3af3

Что экспонента животворящая делает, а?

"Требования российских телеканалов к Google достигли ₽2 ундециллионов"

Надо нашим законодателям рассказать про https://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F_%D0%90%D0%BA%D0%BA%D0%B5%D1%80%D0%BC%D0%B0%D0%BD%D0%B0, вообще хорошо будет.

https://opensource.org/blog/the-open-source-initiative-announces-the-release-of-the-industrys-first-open-source-ai-definition

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

OSI опубликовали критерии того, может ли считаться AI модель open source.

Критерии, в целом, мутные.

Ждем теперь, когда FSF опубликует критерии свободной AI модели!

По мне так это все чушь, open source AI model - это когда исходники применялки идут под открытой лицензией.

Напомню, что у той же ID Software код часто шел под #GPL, а вот данные для игрушек всегда были закрыты, и, тем более, инструменты для подготовки этих данных.

Понимаю коллег, хочется бесплатно и побольше, но получается какая-то херня.

#llvmweekly #rant

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696

TL;DR - хочется уметь красиво выводить в отладчике не встроенные типы, для этого предлагается завести секцию, в котороую писать bytecode, который умеет выводить на эран те или иные типы в программе.

Почему не положить туда готовые python форматтеры, которые уже есть, и написаны?

"The logical next step would be to store full Python formatters instead of summary strings, but Python code is larger and more importantly it is potentially dangerous to just load an execute untrusted Python code in LLDB.

To address these problems, I’m proposing a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers"

Объяснение не стоит и выеденного яйца, потому что ТЫ УЖЕ ЗАПУСТИЛ этот бинарь, запусти и Python, в песочнице.

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/10

Или возьми готовый VM, в который llvm уже умеет (hint - #WebAssembly, #bpf, #ebpf https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/12).

Но нет, это было бы слишком просто, на таком фиолетовое не получить.

Вообще, удивительно, в маленький #harfbuzz тащат большой #WebAssembly (https://xn--r1a.website/itpgchannel/1201), а в большой LLDB (который уже умеет в #WebAssembly) тащат самопальный байткод...

Где логика-то?

Тут прямо Уотергейт для проклятого SJW #ddv

https://dmpwn.info/

TL;DR - обвиняют в педофилии, не меньше.

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

Рубрика "новости из дурки".

https://habr.com/ru/articles/853972/

У нас тут новая интрига в картиночных генераторах.

На Image-арене всех побивает некая Красная Панда.

Причем хорошо так побивает. С оттяжкой.

Народ в сети просто голову сломал и делает ставки.

Я поресерчил твиттор.

Михаил Парахин из Microsoft, похоже, знает, кто это такие. Он говорит, что они существуют уже некоторое время, говорят на английском языке, и, что Adobe - это близко по смыслу. Он также сказал, что это не OpenAI, не Black Forest Labs, не Mistral и не Google.
https://x.com/MParakhin/status/1851287090748953038

Я был уверен, что это Квай\Клинг\Колорс (красные китайские панды). Если они англоговорящие, не французы и не китайцы, то кто?

Runway или Canva или Recraft?

Еще раз, это не китайцы

Наваливайте ставки в коментах.

@cgevent

Vaxry (главный разработчик #hyprland), конечно, тот еще малолетний засранец.

Вот есть такой тред:

https://github.com/hyprwm/Hyprland/issues/3373

К нему пришли с просьбой запилить triple buffering в Hyprland.

* https://github.com/hyprwm/Hyprland/issues/3373#issuecomment-1731278205 - он не разобрался с сутью предложения, и далее и везде начал называть это хаком.

* проигнорировал опыт других DE (https://github.com/hyprwm/Hyprland/issues/3373#issuecomment-2189451677)

* сказал, что потом сделает другим способом, и лучше - https://github.com/hyprwm/Hyprland/issues/3373#issuecomment-2189991235 (спойлер - не сделал)

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

Потому что, конечно, eye candy - прикольно, но когда не работает базовая функциональность - https://github.com/hyprwm/Hyprland/issues/4213 - это такое себе.

https://github.com/marienz/nix-doom-emacs-unstraightened/pull/36#issuecomment-2447199735

TL;DR - разрабы Google в своих OSS проектах должны отдавать авторские права Google, а контрибуторы - подписывать гугловый CLA.

Песенка менеджера https://music.yandex.ru/album/2374733/track/20796127
Такое нам по душе!

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

Гля какая красота!

Оказывается, Линусу можно то, что нельзя #Kent, а именно, тащить в -rc* ветку какой-то новый код, вне рамок merge window.

Очень некрасиво, как по мне.

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

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fc810ae3ae110f9e2fcccce80fc8c8d62f97907

vs.

https://lore.kernel.org/all/5b887fe4c580214900e21f6c61095adf9a142735.1730166635.git.jpoimboe@kernel.org/

По мне так второй патч (оригинал) существенно более понятен, ну и особо доставляет тот факт, что Линус, по сути, присвоил себе авторство этой идеи.

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

TL;DR - прилично народу, у которых есть "ценное мнение", "забыли спросить", и они перевозбудились.

"Как это", говорят, "определение Open #AI, и без нас"?

#ml #prog #meme

#rant

Каждый уважающий себя растаман считает своим долгом впендюрить какие-то свои сборочные настройки в release/dev profile. #cargo

Например, https://github.com/pop-os/cosmic-panel/blob/master/Cargo.toml#L16

Проблема в том, что эти дети не понимают, что творят.

Они, наверное, думают, что делают мне хорошо тем, что их программа у меня будет собираться в 10 раз дольше, и работать на полпроцента быстрее.

Нет, это не так.

Меня это, в конце-концов, заебало, и я решил это починить.

Благо, https://doc.rust-lang.org/cargo/reference/profiles.html это, вроде, позволяет - запили свой профиль, да передай его в cargo --profile.

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

* Если попробовать запилить полностью новый свой профиль, то cargo ругается, и говорит, что любой мой кастомный профиль должен делать inherit от какого-то существующего модуля.

* А если сделать наследование от profile.release, то я получаю в нагрузку все эти лютые донастройки от автора софта.

В общем, как обычно, пришлось решать проблему по рабоче-крестьянски, а именно:

* https://github.com/pg83/ix/blob/main/pkgs/bld/rust/devendor/scripts/strip.py - выпиздить к хуям все авторские экзерсизы. Я было хотел сделать честно, через парсинг toml, но, как оказалось, toml там уже совсем не toml (но об этом в другой раз), поэтому регулярочкой.

* https://github.com/pg83/ix/blob/main/pkgs/die/rust/cargo.sh#L130*-L137 - после выпиливания гениальной авторской мысли, доливаем свои, хорошие, настройки, в которых заведомо нет LTO.

https://www.perplexity.ai/search/what-are-the-main-security-fea-pxhe6YnqRRm1HMrN4osHUg

"These features collectively position stal/IX as a secure choice for users seeking a reliable Linux distribution tailored for enterprise-grade applications"

Знай наших!

Продолжаю свои страдания по rust. #rant

TIL что

cargo build --package A --package B

и

cargo build --package A
cargo build --package B

- это две разные команды!

Да, да, собрать два артефакта одновременно - это совсем не то же самое, что собрать их последовательно.

Как так получается?

Очень просто, #cargo, когда ему надо выполнить первую команду, строит объединение feature флагов этих двух пакетов, и собирает каждый их этих пакетов с объединением их флагов.

Вот и получается, что, по отдельности, пакеты собираются, а вместе - https://gist.github.com/pg83/d2b61ba29587503d58d191a98829f526

Такое ощущение, что разработчики cargo однажды решили, "а давайте вообще все сделаем по-другому". Не "хорошо" или "плохо", а просто иначе.