Собственно, сабж.

У меня был не очень удачно выбранный монитор. Заказывал через интернет с доставкой на дом. В характеристиках было написано, что он матовый, а он оказался глянцеватый. PPI был 69,9335609549936 (1920x1080; 31,5"). В целом пользоваться можно было, но... Чем лучше монитор тем лучше же.

Поэтому я взял и купил себе монитор 2560x1440, 27". Матовый. И теперь у меня монитор с PPI 108,78553926332337.

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

Собственно, сабж: https://www.phoronix.com/news/X.Org-No-Byte-Swapped-Clients

После недавних дискуссий о том, что Fedora планирует отключить поддержку клиентов с перестановкой байтов для сервера X.Org, чтобы закрыть еще одну «большую поверхность атаки» с устаревшей кодовой базой сервера X11, апстрим сервера X.Org теперь отказался от этой поддержки по умолчанию. ... хотя это поведение можно изменить с помощью новой опции. Эта функция «клиентов с перестановкой байтов» предназначена для клиентов X.Org/XWayland, отличающихся последовательностью байтов ЦП от подключения к серверу X.Org.

Собственно, сабж:

От Vladimir Fyodorov (2:6035/3.1) к All 
> Пользователь Reddit'а Fine_Crazy3177 сообщил о начале работы над
> программным обеспечением TVU BBS, написанном на Golang. Результаты
> двухнедельной работы выложены им на github.

Собственно, теперь можно собрать Mutter в GNOME в Wayland only версии: https://www.phoronix.com/news/Mutter-Optional-XWayland .

Mutter в GNOME теперь позволяет отключить поддержку XWayland во время сборки, если это необходимо. Это часть более широких усилий GNOME, направленных на то, чтобы сделать поддержку X11 необязательной и, в конечном итоге, создать современную среду только для Wayland, если это необходимо, и без использования устаревшего X11.

eMKatic — кроссплатформенный эмулятор современных ЭКВМ серии «Электроника», который поддерживает скины МК-152, МК-152М, МК-1152 и МК-161. Написан на Object Pascal и собирается при помощи Lazarus и Free Pascal Compiler.

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

>>> Скачать

В продолжение недавней темы Урезаешь ли ты $PATH для обычного юзера, $USER? .

В той теме почему-то никто не угадал почему не стоит расширять $PATH обычного юзера. И я тоже не угадал. И это двойка по информационной безопасности всем нам.

Так вот, из $PATH обычного юзера вырезают /sbin, /usr/sbin и /usr/local/sbin чтобы сильно усложнить жизнь потенциальному взломщику. Если он взломает обычного юзера и повысит привилегии... у него может быть даже обзор системы сильно ограничен при таких настройках. Не говоря уже о том, что ему будет сложнее выполнять бинарники из sbin'ов с уже повышенными им привилегиями.

А чем вредно для секурности sudo? Например, этим:

После выполнения sudo существует временной отрезок, в течение которого повторное выполнение команды sudo не требует пароль (что удобно для взлома вашего компьютера со стороны rootkits и хакерских атак).

Поэтому su лучше чем sudo, а отсутствие /sbin, /usr/sbin и /usr/local/sbin в $PATH обычного юзера лучше чем их наличие там. Такова серьёзная секурность.

Собственно, сабж. Возник тут спор по поводу. Есть мнение, что в $PATH у юзера в любом случае не должно быть директорий /sbin, /usr/sbin и /usr/local/sbin . Т.е. даже не так, что по дефолту их может и не быть, но если юзер хочет, то пожалуйста, а так, что если их туда вписать, то последствия будут катастрофические. А у тех, у кого пока всё OK, дескать, эти ужасы просто ещё впереди.

Я считаю, что ничего плохого от расширения $PATH у юзера не будет. Доступность бинарников не даёт автоматически права root'а. Чего тут бояться-то? ¯\_(ツ)_/¯

Собственно, сабж. В новой версии:

• Когда --autoindent и --breaklonglines совмещены, нажатие <Enter> в определенной позиции больше не съедает символы.

Скачать: https://www.nano-editor.org/dist/v7/nano-7.1.tar.xz

Собственно, сабж: https://forum.altlinux.org/index.php?topic=47025.msg376962 .

Готов седьмой выпуск стартеркитов на базе бранча p10 для i586, x86_64, aarch64 и armh.

Изменения:

• Основные ядра 5.10.156 / 5.15.80
• make-initrd 2.31.0
• Chromium 107
• Firefox ESR 102.4.0
• kde5: 5.98.0 / 5.25.5 / 22.08.1
• Mate: 1.26
• lxqt 1.2
• server: добавлена возможность установки на btrfs
• jeos-{sysv,systemd}: добавлены drm модули ядра и firmware в инсталятор
• для установки live теперь используется классический инсталятор, который находится внутри live.

Собственно, сабж: https://www.philipotoole.com/how-i-found-a-bug-in-sqlite/ .

During my load testing of Queued Writes, I would sometimes run the rqlite CLI, and keep an eye on test progress by issuing the following command periodically:

127.0.0.1:4001> SELECT COUNT(*) FROM logs

Imagine my surprise when I would occasionally get back:

ERR! database disk image is malformed

Собственно, сабж: https://www.phoronix.com/news/Qt-6.5-Wayland-Native-Interface .

Инструментарий Qt6 представил понятие специфичных для платформы объектов через пространство имен QNativeInterface, и теперь в Qt 6.5 должна появиться поддержка собственного интерфейса Wayland для разработчиков приложений, желающих напрямую взаимодействовать с дескрипторами объектов Wayland.

Qt 6.5 с поддержкой собственного интерфейса Wayland через QNativeInterface значительно упрощает взаимодействие с объектами Wayland непосредственно из кода вашего приложения Qt. С Qt5 можно было взаимодействовать напрямую, используя QPlatformNativeInterface, но беспорядочно, а в Qt6 до этого момента просто не было поддержки.

Собственно, сабж: https://www.phoronix.com/news/GCC-Modula-2-Ready .

«Модула-2» использовалась на рабочих станциях «Лилит», российских навигационных спутниках ГЛОНАСС и различных устаревших встроенных системах. В течение нескольких лет страстные разработчики Modula-2 пытались объединить интерфейс языка Modula-2 с GCC.

И у них, по ходу, получилось, да.

Собственно, сабж: https://www.phoronix.com/news/SDL-3.0-Wayland-Default-Prefer .

Итан Ли повторно объединил изменение, чтобы предпочесть Wayland X11, когда библиотека SDL построена с включенной поддержкой Wayland. Теперь есть надежда, что код SDL и более широкий код драйвера/композитора Wayland/сопутствующей экосистемы станет более зрелым и достаточно хорошим, чтобы его можно было использовать по умолчанию, а не идти по маршруту X11/XWayland. ... Это изменение было объединено с основной веткой SDL Git. SDL Git — это место, где началась разработка SDL3.

Собственно, сабж: https://pldb.com/posts/niklausWirth.html .

В нём он рассказывает, что для своих языков как основу использовал философию Algol 60. А создателям новых языков программирования советует посмотреть как он сделал Oberon.

Собственно, вопрос. Лично я использую. В /etc/fstab только актуальные для загрузки системные разделы. 3 дополнительных раздела прописаны в отдельном файле и монтируются по команде от root'а.

Собственно, после обновления браузеров начал замечать, что Brave (на Chromium'е) начал грузить проц. Начал разбираться. В Firefox'е тоже самое. Wayland ситуацию не улучшает. Более того, в нём опции командной строки "--enable-unsafe-webgpu --enable-features=Vulkan,UseSkiaRenderer" включают аппаратную поддержку с ограничением скорости. В иксах скорость не урезается. Как теперь включить аппаратное ускорение в Firefox'е вообще не нашёл.

Почему такое происходит? А из-за чёрных списков конфигураций. По ходу, Linux'овый amdgpu на Radeon RX 6400 теперь помечен в браузерах как более чем бажный. Настолько бажный, что аппаратное ускорение в браузерах с ним теперь только на страх и риск юзера. А по дефолту для стабильности всё рисуется процом.

Собственно, сабж: https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL .

Google Chrome has offered JPEG-XL (JXL) image support via a feature flag (chrome://flags/#enable-jxl) since Chrome 91 while with Chrome 110, Google is looking at deprecating this still-fresh-and-new image format.

А сабж таки случился, да: https://docs.python.org/3.11/whatsnew/3.11.html .

Положено начало урезанию стандартной библиотеки. Пока что половину только заdeprecate'или, удалять будут года через 2.

И вот тогда, как мне думается, будет закат Python'а. Почему? Ну, теперь слишком большой акцент будет на pypi.org. А его как раз таки и начнёт колбасить. Во-первых, ряд библиотек там уже подзаброшены. И на них могут основываться более живые. Вряд ли всё протестируют до самого последнего момента. А потом всё внезапно развалится. Во-вторых, с таким подходом наступит эпоха библиотек наподобие той «leftpad.js». Т.е., очевидно, людям нужен функционал стандартной библиотеки и выпиленное будут запиливать новыми 3rd party библиотеками. И вот тут наступит эпоха хаоса и бэкдоров. Очевидно, что не все будут честно запиливать положенный функционал, левые библиотеки регулярно удаляются оттуда, а программисты будут во всём этом путаться ещё больше.

Собственно, сабж: https://www.phoronix.com/news/Intel-i486-Linux-Possible-Drop .

So I *really* don't think i486 class hardware is relevant any more. Yes, I'm sure it exists (Maciej being an example), but from a kernel development standpoint I don't think they are really relevant.

At some point, people have them as museum pieces. They might as well run museum kernels.

Moving up to requiring cmpxchg8b doesn't sound unreasonable to me.

Собственно, сабж.

https://kde.org/announcements/1-2-3/2.0/