Интерестно узнать мнения тех кто пользуется/пользовался если можете киньте конфигурацию

Эмулятор пользовательских приложений системы команд Эльбрус (qemu-e2k) обновился до версии 1.2. Скорректирован список неподдерживаемых операций.

Эмулятор qemu-e2k обеспечивает возможность, используя операционную систему семейства Linux запускать прикладные программы для операционных систем семейства Linux в машинных кодах Эльбрус (e2k) на компьютере архитектуры x86-64.

Эмулятор qemu-e2k (release 1.2) соответствует срезу версии 11.0.1 из основного репозитория проекта.

Версия qemu-e2k (release 1.2) поддерживает работу с приложениями, собранными под платформу Эльбрус версий системы
команд elbrus-v2 - elbrus-v6. По умолчанию задаётся версия системы команд elbrus-v6.

Версия qemu-e2k (release 1.2) имеет следующие ограничения:

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

>>> Зеркало QEMU с патчами поддержки архитектуры Эльбрус (openelbrus.ru)

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

Суть такова. Два ноута, два монитора. На ноутах изображение комфортно при 125% на одном, 200% на другом. На мониторах - 100% и 225%. Подключаться могут все ко всем, и без мониторов использоваться.

Ну и начинается адок. Гнум не умеет ничего кроме 100%, 200% и 300%, но вроде мониторы запоминает. Кеды умеют любой масштаб, но привязывают его к конкретному монитору плохо, бывает сбиваются. И размеры панелей, и величины в latte-dock абсолютные, хнык-хнык

Возможно ли счастье? Лучше, конечно, кеды поправить.

Ошибка вызвана автоматической обработкой содержимого каталога a .git/, когда он размещён в одном каталоге с открываемым файлом. В этом случае Emacs при открытии файла запускает команды git ls-files и git status, выполняемые в контексте содержимого .git/. Для выполнения кода достаточно открыть в Emacs файл из каталога, в котором имеется подкаталог .git/ с файлом конфигурации config, включающим опцию core.fsmonitor с указанной атакующим командой для запуска.

Сопровождающие GNU Emacs отцы отказались устранять уязвимость, считая, что проблема на стороне git.

>>> Подробности (github.com)

Один из разработчиков дистрибутива Devuan представил проект GTK2-NG, который будет развивать форк библиотеки GTK2, нацеленный на продолжение её сопровождения и обеспечение качественной работы в современных дистрибутивах. Поддержание форка позволит продолжить поставку в Devuan приложений, завязанных на GTK2, после прекращения поддержки GTK2 в дистрибутиве Debian 14, релиз которого ожидается летом 2027 года.

Разработчики проекта GTK прекратили сопровождение GTK2 более пяти лет назад, а пакеты с GTK2 уже исключены из официальных репозиториев дистрибутивов Red Hat Enterprise Linux, SUSE Linux Enterprise Server, openSUSE и Arch Linux (доступен через AUR). Из значимых проектов GTK2 продолжает использовать звуковой редактор Ardour, но данный проект не зависит от внешних библиотек и поддерживает собственный форк GTK2 - YTK (opennet.ru). В репозитории Debian остаётся около 150 пакетов, связанных зависимостями с GTK2, среди которых afterstep, Double Commander, fpc, gkrellm, gmpc, hexchat, lazarus, mplayer, navit, pidgin, sane-frontends, scim, sylpheed, tickr, tilem, uim, usermode, xsane, xzgv и z88.

В GTK2-NG добавлено несколько десятков изменений, в основном связанных с переносом исправлений, распространявшихся в форме патчей в пакетах из AUR и Debian, и исправлением предупреждений, выдаваемых компилятором. Из улучшений отмечается модернизация функции сортировки массивов g_sort_array и замена алгоритма масштабирования для повышения чёткости пиктограмм. В виджете выбора файлов (filechooser) решены имевшиеся проблемы и проведена оптимизация отображения в виде иконок содержимого каталогов с большим числом файлов. Протестирована сборка с использованием GCC 14 и Clang 21.

Из планов на будущее отмечается перенос изменений из форка GTK2, развиваемого участником проекта Xlibre - stefan11111, а также бэкпортирование кода из YTK (github.com), форка GTK2 от проекта Ardour. Среди задач также называется проверка сборки в GCC 15 и добавление поддержки использования libppd для вывода на печать на системах с CUPS 3.x. Не исключается задействование лицензии GPLv3 для нового кода и смена названия для исключения претензий от проекта GNOME.

>>> Источник: OpenNET (opennet.ru)

Сайт downforeveryoneorjustme.com (доступный также через isup.me) проверяет, отвечает ли веб-сервер в заданном домене. Но если все REST-запросы на сайте выдают 500, сайт всё равно считается рабочим.

Существует ли столь же глобальный сайт, способный проверять работоспособность глубже? Хотя бы для популярных сайтов с миллионами посетителей.

1. https://syscalls.mebeim.net – всегда свежие данные; есть сигнатура вызова; JSON для отдельных версий ядра.

2. https://syscalls.defoy.tech – еженедельное обновление; syscalls.tar.gz всех CSV.

3. https://x64.syscall.sh – только arm, arm64, x86; есть сигнатура вызова; есть API сайта.

4. https://filippo.io/linux-syscall-table – Linux 6.16-rc1; нечёткий поиск по имени; исходники этого HTML на Go.

Enjoy!

Хотя формально уже суббота, но тем не менее.

Помните ли вы те благословенные времена, когда деревья были выше, трава зеленее а на ЛОР-е блистали Царь, Метапрог и Космоспек? Я уж решил что все, старость-не-радость, увяли помидоры, но эта пятница сумела лично меня удивить. В казалось бы скучный, интересный только узким специалистам тред Чему равен логарифм корня из двух в IEEE754 (fp32)? ворвался подобно ракете наш новый Чемпион - Космический Инженер и Вычислитель, бескромпромиссный расставитель клоунов @Frohike! Конечно ему пока далеко до прошлых легенд ЛОР-а по харизме, но тем не менее я чувствую большой потенциал.

Вот список цитат которые ИМНО достойны мемориза. Начало тут (linux.org.ru). Изначально речь шла о том, что в одной из библиотек неверно считается выражение log(sqrt(2)):

Разве не очевидно, что любые операции с иррациональными числами приводят к приближённым результатам?

В чём проблема «логарифм корня из двух»? Не написали по какому основанию логарифм, но это издержки постсоветского образования, ничего не поделаешь

В том что он неправильно считается в newlib?

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

Нет разницы куда округлять, погрешность результата будет в пределах плюс/минус точности вычислений. Чем больше итераций, тем больше ошибка округления будет накапливаться в любом случае. Это значит то, что совершенно без разницы 0x3eb17217 или 0x3eb1730d (про значение log(sqrt(2))

Да, я тоже реализую космическую программу, нет разницы куда и как округлять. А не надо вычислять экспоненту, в этом нет никакого практического смысла. Вы теоретик что ли?

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

Доказательства в студию. Статьи в профильных журналах…

Первая форма, ну вы понимаете.

в какой именно области космической программы не имеет никакого значения число знаков после запятой?

Да в любой.

М. Ю. Овчинников ВВЕДЕНИЕ В ДИНАМИКУ КОСМИЧЕСКОГО ПОЛЁТА, Число обусловленности — изучайте до просветления.

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

В программе Аполлон абсолютно плевать было на точность вычислений, корректировка курса была по наблюдаемым объектам, точнее если Луну видно в иллюминатор, значит летим правильно, не видно - корректируем курс руками. На «Аполлонах» этот сраный калькулятор, де-факто, только жрал электричество и обогревал пространство, больше он нафиг был не нужен.

Любой калькулятор имеет ОС реального времени

ТС неопытный и толком не знает что ему нужно, а ЭВМ всё сделала как надо оптимальным путём, ибо нет никакой значимой разницы между желанием пользователя и результатом машины. (про то, что log(sqrt(2)) в newlib посчитан с ошибкой в последних 12ти битах мантиссы из 23х).

Вы телепат?👽

Хуже, я Инженер.

(c) @Frohike, все права защищены.

Какой хостинг репозиториев выбрать? НЕ github! Какой-нибудь более открытый и свободный. Savannah?

Какими командами инициировать создание нового проекта?
Никогда не пользовался git всерьёз, делал только git clone каких-то чужих проектов.
Т.е. нужно залить имеющийся тарбол в новый проект и создать необходимые ветки.

Зачем это может быть нужно?

Ответ простой — для виндовых игр. Например, авторы модов часто для обливиона, морровинда не заморачиваются с тем, чтобы названия директорий в моде было в том же регистре что и в игре. Таким образом, при подключении модов, игра просто не будет видеть файлы этих модов, потому что она будет искать их по тому пути, который прописан в игре. Аналогично, например, и с Crusader Kings 2, пусть она и нативная. Там моды приходиться портировать под линукс, чтобы все файлы и директории назывались в одном и том же регистре.

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

Состоялся релиз GNU libunistring 1.4 — библиотеки, которая позволяет работать с Unicode-строками в программах на C, а также со строками C в соответствии со стандартом Unicode.

Изменения в этом выпуске:

• Алгоритмы и таблицы с данными обновлены до стандарта Unicode 17.0.
• Исправлены проблемы с работой функций u*_grapheme_next и u*_grapheme_prev для символов Indic, Emoji и индикаторов региона.

Проект поддерживает UTF-8, UTF-16 и UTF-32. Распространяется на условиях LGPL 2.1.

>>> Код (gnu.org) на savannah.gnu.org

>>> Сообщение в списке рассылки (gnu.org)

При этом в dmesg:

[ 2853.507915] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2853.510098] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
[ 2853.510110] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
[ 2853.513166] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
[ 2853.513178] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
[ 2853.514046] ata1.00: configured for UDMA/133
[ 2893.485021] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2893.487183] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
[ 2893.487195] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
[ 2893.490195] ata1.00: ACPI cmd f5/00:00:00:00:00:00(SECURITY FREEZE LOCK) filtered out
[ 2893.490206] ata1.00: ACPI cmd b1/c1:00:00:00:00:00(DEVICE CONFIGURATION OVERLAY) filtered out
[ 2893.491062] ata1.00: configured for UDMA/133

cat "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'

- не печатает

Понадобилось тут завести модем с eSIM в онтопике. Использовал модем Qualcomm® Snapdragon™ X16 LTE Modem на планшете Microsoft Surface Go 2 на Debian GNU/Linux 13 (trixie).

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

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

Было это братцы давным-давно. Черные силы MS пришли войной… @Dimez, сорри, кликбейтный заголовок :)

Наткнулся (внезапно на ютубе, но там нечего смотреть).

Суть: Betanet это как тор и I2P но без их недостатков:

1. обязательная маскировка трафика под обычный интернет

2. Не опирается на волонтёров: релеи получают оплату за транзит трафика (криптой)

3. развитие протокола управляется голосованием.

Приглашают разработчиков, предлагают деньги (си, раст)

Я пока не всё понял, как у них что будет работать.

Зачем нужен неподцензурный интернет, полагаю, не надо объяснять.

вот спеки поректа: https://ravendevteam.org/betanet/

Часто бывает так, что в очередной минорной версии разработчики Wine что-нибудь ломают для одной конкретной программы или игры, при этом все остальные программы работают нормально. И пользователю приходится либо откатываться до предыдущей версии Wine (это возможно не во всех дистрибутивах), ставить PlayOnLinux, что не всем нравится, либо компиллировать самому.

Чтобы предотвратить это неудобство, я с некоторых пор делаю бинарные сборки Wine и выкладываю их для всех желающих. Располагаются они здесь. Когда задумывал это, то вдохновлялся примером PlayOnLinux, которые тоже делают собственные бинарные сборки Wine, но обладают некоторыми недостатками:

1. Выходят нерегулярно.
2. Скрипта, который их формирует, я так и не нашел.
3. Мне нужна еще версия с патчами Staging, а они не для каждой версии их делают.

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

Преимущество бинарных сборок:

1. Идут практически любом современном дистрибутиве. За абсолютно все дистрибутивы любой давности ручаться не буду, сам проверял только на паре дистрибутивов, поэтому хотелось бы чтобы вы их протестировали и подтвердили или опровергли это утверждение.
2. Для использования не требуется ничего, установленных зависимостей для Wine. Сам системный Wine при этом даже необязателен.
3. Можно иметь хоть с десяток разных версий Wine для разных программ и с легкостью переключаться между ними без каких-то переустановок. Чтобы установить бинарную сборку, достаточно лишь ее распаковать в любой каталог.

В процессе создания бинарных сборок я целенаправленно не применял никаких сторонних патчей. В версии с патчами Staging присутствует только набор патчей из Staging и больше ничего. В ванильной версии не применяются никакие патчи. Даже несмотря на то, что начиная с какой-то версии из ветки 1.9.x Wine стало невозможно скомпиллировать с помощью gcc 5.3.0 и патч довольно оперативно написали, я предпочел откатиться до gcc 4.8.5, чем применять этот патч. Сомневающимся могу порекомендовать скачать мой скрипт, собрать Wine самому с помощью gcc 4.8.5 и после чего сравнить свой хэш получившегося архива с моим.

Для чего эта тема? Во-первых, для информации. Может кому-нибудь пригодятся мои бинарные сборки, мне будет приятно. И еще протестируйте их пожалуйста на своих разных дистрибутивах разных версий, чтобы посмотреть, действительно ли они дистронезависимые или нет?

И еще раз ссылки:

1. Сайт с бинарными сборками Wine
2. Скрипт, по которому они формируются

P.S. Перед использованием скрипта отредактируйте его и измените содержимое переменных WORKDIR (каталог, в котором будет компиллироваться Wine) и GCC_VERSION (версия GCC, которая применяется для сборки) в соответствии со своими предпочтениями. А то там сейчас стоят мои значения.

Обновлено 04.02.17:
В связи с тем, что после выхода Wine 2.0 сменилась нумерация промежуточных версий (промежуточная версия теперь 2.1 и все исходники будут лежать в папке 2.x и еще они сменили формат архива), то скрипт для сборки разделен. Скрипт wine_build_1.9.x-2.0.sh - для сборки всех предыдущих версий Wine до версии 2.0 включительно и wine_build-2.x.sh - для всех версий после 2.0. Да, это неудобно. Но это лучше, чем если бы в одном скрипте писать кучу костылей по парсингу мажорной версии, минорной версии и их какого-то совмещения. Размер скрипта значительно увеличился бы, он стал бы трудночитаемым и вряд ли это решение было бы совсем безглючным.

Обновлено 25.10.18:
Я закрываю формирование бинарных сборок в связи с тем, что Wine в последнее время оброс сторонними патчсетами, вроде esync, да и самому мне это все надоело. К тому же появился Steam Play. Все предыдущие сборки вы можете скачать отсюда, но новые формироваться вряд ли будут. Там же вы найдете скрипт, с помощью которого можно будет сделать свою собственную сборку.

Обновлено 24.10.20:
В силу некоторых причин пришлось снова расчехлить мой скрипт для формирования бинарных сборок. Только сами бинарные сборки я выкладывать не буду: мне и влом, и места на хостинге жалко, да и проблемы совместимости с разными версиями glibc в разных дистрибутивах.
Вместо этого я адаптировал сам скрипт согласно современным реалиям и выложил его на GitHub - пользуйтесь, если хотите. Скрипт пришлось практически полностью переписать, убрать костыли, а заодно и поддержку сборки из git. Для сборки из git надо писать отдельный скрипт, поскольку там другие пути и сценарии распаковки и сборки. Может займусь этим когда-нибудь.

Здравствуйте,

Toolkit-ы не использую.

Самый очевидный способ - это при сборке пускового файла поставить на компьютер все нужные библиотеки x11 и wayland одновременно. Это позволяет собрать результат, но это также требует в зависимостях пакета указывать runtime-версии всех нужных библиотек опять же и под x11, и под wayland. В результате при установке пакета в систему влетят библиотеки из другого дисплейного менеджера, что вроде бы некритично, но может и не очень красиво выглядит. Это правильный способ или можно всё решить как-то изящнее? Например, можно сделать экспорт функций из runtime-библиотек, тогда эти библиотеки не будут явно требоваться при старте приложения. Плюс вроде в этом есть, но как-то всё это стрёмно выглядит. И если экспорт функций в x11 прокатывает без проблем

void* handle=dlopen("libX11.so.6", RTLD_LAZY);
    if (!handle)
    {
        fprintf(stderr, "Failed to load libX11.so.6: %s\n", dlerror());
        return false;
    }
    exp_XConvertSelection=(PFN_XConvertSelection)dlsym(handle, "XConvertSelection");
    exp_XGetWindowAttributes=(PFN_XGetWindowAttributes)dlsym(handle, "XGetWindowAttributes");

, то wayland вообще обрубил меня на первой же функции:

uint32_t wlnd_proxy_get_version(struct wl_proxy *proxy)

Даже выбросив все обращения на функцию wlnd_proxy_get_version в программе я всё равно получаю на ней ошибку линковки, потому что wayland где-то внутри всё равно к ней обращается.

Таким образом мне нужно просто понять, стоит ли тут мудрить или просто кидаешь в пакет двойные зависимости и спишь спокойно ?