LINUX.ORG.RU

Сообщения wandrien

 

qman — man page viewer здорового человека

Форум — Talks

Откопал ссылку на такую штуку в Арчевики. Простая программа, реализующая для man pages в терминале то, что еще 35 лет назад было в справочных системах под DOS-ом, + большее.

  • Страницы оглавлений, отображающие все маны, установленные в системе, сгруппированные по категориям
  • Интерактивный инкрементальный apropos и whatis (search as you type)
  • Инкрементальный поиск по странице
  • Активные гиперссылки на другие маны
  • Активные гиперссылки на http(s) и email адреса.

Навигация вверх-вниз по странице сделана максимально удобным образом:

  • Если в направлении листания на экране есть следующая ссылка, фокус переходит к ней.
  • Если в направлении листания на экране следующей ссылки не видно, текст сдвигается на 1 строку.

Программа реализована на Си с минимумом зависимостей.

Зависимости в собранном виде и размер:

vadim@aquila:~$ ldd /usr/bin/qman
	linux-vdso.so.1 (0x00007dbe6007f000)
	libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007dbe5ffa3000)
	libinih.so.0 => /usr/lib/libinih.so.0 (0x00007dbe5ff9e000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007dbe5fdb2000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007dbe60081000)
vadim@aquila:~$ ls -lh /usr/bin/qman
-rwxr-xr-x 1 root root 116K мая 29 11:43 /usr/bin/qman

Сорцы и скриншоты тут: https://github.com/plp13/qman

 , qman,

wandrien
()

Работа с выводом в терминале как с текстом для последующей обработки

Форум — General

Какие вообще есть решения для этого? Чтобы безмышевозанья.

Иными словами, как программно получить данные из экранного буфера?

 

wandrien
()

Wikipedia — вахтёрская помойка

Форум — Talks

Извиняйте, просто навеяло ночью.

Вот пример:

https://web.archive.org/web/20240128100538/https://en.wikipedia.org/wiki/Zero_Install

По меньшей мере с 2005-го года, то есть почти 20 лет лежала статья, никому не мешала. Содержала ссылки на другие похожие решения и технологии.

В январе 2024-го явился вахтёр и статью удалил как «незначимую».

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

Щас еще осталось поисковые системы полностью на ИИ заменить, и в инете вообще ничего невозможно будет найти ни по какой теме.

 ,

wandrien
()

Линукс и жор памяти

Форум — Desktop

Данная тема создана по следам этого: 750 мб занятой оперативы на старте дистрибутива с XFCE - это норма?

Люди так удивляются, что 4 ГБ – это мало для работы, будто то ли на на дворе 2005, то ли Linux может магически превратить 4 ГБ в 16, и еще пару ядер накинуть на сдачу.

Но тем не менее, вопрос, сколько ест максимально голая система – интересный. У меня Арч, и я решил посмотреть, что у меня с потреблением памяти. А тему эту я решил создать, чтобы ссылаться на неё при необходимости.

Вот картина потребления оперативной памяти без логина в графический сеанс:

https://ibb.co/BNrCWMk

Я отключил все службы, которые нужны лично мне, такие как docker, оставил только системные штуки. Видно, что запущен systemd с базовыми сервисами, NetworkManager, а также lightdm с графическим сеансом, через который отображается окно ввода логина-пароля. Не запущены также штуки, которые часто суют в дистрибутивы по дефолту – cups, wsdd и т.п. (У меня их на этой машине и нет.)

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

А вот после входа в графический сеанс пользователя:

https://ibb.co/m5WCWvP

Опять-таки, я закрыл все штуки, которые лично мне нужны, такие как syncthing или автозапускаемый сеанс в terminator.

Если вместо графической оболочки из нескольких отдельных программ использовать компактный WM типа icewm, то можно подсократить эти числа, чтобы они были ближе к числам на 1-м скриншоте. Но не вижу в этом большого смысла.

Короче говоря, если сравнивать с виндами, то Linux в 2024-м может базово потреблять ОЗУ где-то на уровне Vista. Всё в ваших руках: хотите потребление как у Висты и запуск на старом лаптопе – это возможно, хотите ни в чём себе не отказывать на системе с 64 гигами – это тоже возможно.

На практике после входа в графический сеанс, автозапуска всех нужных служб и приложений и открытия тестового редактора с кучей вкладок потребление памяти у меня составляет 800-900 МБ.

 ,

wandrien
()

Intel N100

Форум — Talks

В теме Это правда, что большинство пользовательских программ в linux больше грузят процессор, чем их альтернативы в windows? увидел сообщение от @amd_amd:

CPU: Intel Pentium 4 3.20GHz (2) @ 3.200GHz

И ответ на него от @haydudogni:

Энергопотребление (TDP): 82 Watt

у меня 8 и это APU

Сначала хотел ответить, что нельзя напрямую сравнивать эти процессоры по TDP, потому что между ними технологическая пропасть, и Pentium 4 невероятно устаревший со своим техпроцессом и особенностями архитектуры.

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

Не знаю, насколько слаб старый APU от AMD у ТСа в той теме, но новые процессоры, которые Intel пропихивает в бюджетный сегмент, тоже не радуют:

https://www.youtube.com/watch?v=pCkM8yRQoMs

Если кратко:

В чисто вычислительных тестах показывает производительность на уровне мобильных Core i3 11-го поколения, что весьма неплохо.

В то же время, в ряде тестов проваливается практически до уровня Core 2 Duo. (o_O)

Основная проблема этого SoC — невероятно задушенная пропускная способность ОЗУ. Это становится особенно критично на фоне того, что встроенный GPU критично чувствителен к скорости работы памяти.

Как результат, ноутбук 2024-го года не в состоянии вытянуть Fallout New Vegas и Skyrim. Производительности системы хватает, чтобы воспроизводить ролики с ютуба. Обзорщик явным образом этого не сказал, но к слову «хватает» определённо просится добавка «впритык».

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

 , , n100

wandrien
()

Снова о статической типизации

Форум — Development

Пример задачи:

Имеется некоторая структура данных, доступ к которой в многопоточном окружении защищен мьютексом.

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

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

Легко сообразить, что данная задача решаема на статически типизированном языке. (С разным уровнем костыльности-некостыльности, в зависимости от того, что это за язык.) И нерешаема на динамически типизированном языке.

Усложненный вариант задачи.

В программе имеются мьютексы m1, m2… mN.

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

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

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

 ,

wandrien
()

fastcompmgr — быстрая альтернатива для picom/compton

Форум — Talks

Вышел первый публичный релиз нового композитного менеджера для X11 на основе исходного кода классического xcompmgr.

CPU usages by compositor:

Compositor      move    resize  scroll
fastcompmgr     6.7%    4.4%    1.5%
xcompmgr        7.8%    4.9%    1.6%
compton         26.4%   6.8%    17.1%
picom           29.3%   8.1%    23.1%

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

 , fastcompmgr, ,

wandrien
()

В Debian завезли AUR

Форум — Talks

Выглядит как сборка пакетов здорового человека:

https://github.com/pacstall/pacstall-programs/blob/master/packages/emacs/emacs.pacscript

Правда вебня свёрстана через одно место. Еще поменьше всплывающее окно нельзя было сделать? https://ibb.co/RDDYVvq

 , , makedeb, pacstall,

wandrien
()

Посоветуйте приложение типа mind mapping-а, но не совсем

Форум — Desktop

Называется, сам не знаю, чего хочу.

Что-то среднее между ming mapping и программой для составления презентаций из слайдов. Чтобы на слайды можно было по-быстрому накидать диаграммы и блок схемы, а отдельные элементы диаграммы сделать ссылками на другие слайды, где этот элемент описан подробнее. Такой древовидный набор слайдов с гиперссылками между ними.

При чем мне даже кажется, что я давно под винду видел что-то такое. А вот под линь – вроде не сталкивался.

 , ,

wandrien
()

Простите, я упустил момент, а когда разрабы LibreOffice упоролись?

Форум — Talks

Или это всегда так было?

  1. Открываем LO Writer.
  2. Идём на панель рисования, создаём на странице что угодно, например, прямоугольник.

В этот момент последовательно и с ощутимой ясно видимой задержкой происходят следующие вещи:

  • Тулбар форматирования текста исчезает.
  • Это приводит к тому, что страница прыгает вверх на высоту данной панели.
  • На тулбаре «Стандарт» происходит отключение части кнопок, в процессе этого они одна за другой перемигиваются огоньками, то есть панель обновляется не атомарно.
  • С еще более долгой задержкой обновляется внешний вид линеек.

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

  • Тулбар форматирования текста появляется.
  • Это приводит к тому, что страница прыгает вниз на высоту данной панели.
  • На тулбаре «Стандарт» происходит включение части кнопок, в процессе этого они одна за другой перемигиваются огоньками, то есть панель обновляется не атомарно.
  • В последнюю очередь обновляется внешний вид линеек.

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

Вот как раз такое я имею в виду, когда говорю, что UI у опенсорса обычно сделан из говна и палок. Лучший офисный пакет, согласно коллективному мнению ЛОРа.

UPD: https://drive.google.com/file/d/1tUBerVKMF7FD1CLnMh3GQYociDC0uKeK/view?usp=sharing

 

wandrien
()

О развитии GUI

Форум — Development

Вот пример проблем, которые мешают создавать продвинутые способы интеракции приложений:

  1. Не существует способа узнать положение клавиатурного курсора в окне стороннего приложения. Это необходимо, чтобы открывать произвольные меню и панели «по месту» ввода.
  2. Не существует способа узнать выделенный текст в окне стороннего приложения. Буфер PRIMARY предназначен не для этого, соответственно его содержимое не сбрасывается после сброса выделения.
  3. Не существует надежного способа вставить текст в окно стороннего приложения. Используемые сейчас варианты - это костыли с эмуляцией нажатия клавиш, которые в зависимости от приложения, могут либо не работать, либо давать непредсказуемые эффекты.

Ровно этот же список я мог бы назвать 15 лет назад, с тех пор ничего не изменилось.

Как видно, речь идёт о том, чтобы операции вида «сделать что-то с выделенным текстом» или «вставить результат работы стороннего приложения» могли быть бесшовно интегрированы между приложениями без необходимости хардкодить это в тулките или грузить so-шки с хаками в адресное пространство приложения.

Банальные примеры подобных интеракций:

  • Вставить текущую дату в выбранном пользователем формате.
  • Выполнить выделенный текст как команду оболочки и вставить результат.

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

 

wandrien
()

О пользе хоткеев и межпрограммном взаимодействии

Форум — Development

@qulinxao3 писал:

однако жаль малоиспользуется sam|acme

и в целом логика исполнения текущей строки редактируемого файла(текстового буфера) тем или иным исполнителем и помещение возвращённого результата (побочный итак в глобальности) в тот или иной текстовый контейнер

ззы: ща на ctrl-\ в сode висит Terminal: Run Selected Text ln Active Terminal который при пустом выделении отрабатывает текущую строку - получается нечто парное vim'овскому :r!вотэтовотвыделение

забавно как пламбер оказался не ко времени всё ещё

Я ему ответил:

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

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

Также дополнительно к сказанному в черновике хочу сказать следующее:

Я многократно говорил, что задача DE – интеграция программ. Мне на это отвечают, что «интеграция программ» создаёт монстров, примеры которых мы можем наблюдать в KDE и вообще везде.

Мой ответ на это: правильная интеграция монстров не создаёт. Программы вообще не должны знать о существовании друг друга. Им не нужно линковаться друг к другу и не обязательно иметь so-шки на пару тысяч символов. Всё, что им нужно – предоставлять о себе немного информации.

Всё, описанное ниже, доступно к реализации даже при помощи несложного bash-скрипта для любой DE или вообще без DE. Но конечно грамотная реализация на Си – предпочтительнее.

Итак, сам текст:


Хоткеи запуска приложений:

Super + Q - Запустить предпочитаемый эмулятор терминала
Super + W - Запустить предпочитаемый текстовый редактор
Super + E - Запустить предпочитаемый файловый менеджер
Super + R - Показать лаунчер для быстрого запуска команд
Super + T - Запустить предпочитаемый web-браузер
Super + Y - Запустить предпочитаемый калькулятор

Как видно, горячие клавиши выбраны так, чтобы располагаться подряд в 1-й буквенной строке клавиатуры (QWERTY) и не имеют мненомического значения. Порядок клавиш выбран в соответствии с тем, какие приложения обычно наиболее часто востребованы при работе с типичной UNIX-like системой: в первую очередь вам потребуется терминал, во вторую текстовый редактор и так далее.

Хоткеи, использующие выделенный текст как путь к документу:

Super + Shift + Q - Запустить предпочитаемый эмулятор терминала в указанном каталоге
Super + Shift + W - Открыть указанный файл в предпочитаемом текстовом редакторе
Super + Shift + E - Показать указанный файл в предпочитаемом файловом менеджере
Super + Alt   + E - Показать контекстное меню для указанного файла
Super + Shift + R - Показать лаунчер для быстрого запуска команд и выполнить команду для указанного пути
Super + Shift + T - Открыть указанный URL в предпочитаемом web-браузере

Каким образом DE понимает, что является «указанным файлом/каталогом»:

Первый вариант — если выделен некоторый текст.

  1. Если выделенный текст выглядит как URL, то он и считается указанным.
  2. Если выделенный текст выглядит как полный путь (начинается с символа /), то он и считается указанным.
  3. В ином случае выделенный текст считается файловым путём относительно текущего каталога. Следовательно, необходимо найти текущий каталог.
    • Для этого DE извлекает путь к документу из текущего окна.
    • Если путь является существующим каталогом, то он и считается текущим каталогом.
    • Если путь является существующим файлом, то берётся путь к его каталогу.
    • Если путь извлечь или проверить не удалось, то домашний каталог пользователя считается текущим.

Второй вариант — если текст не выделен.

В этом случае DE извлекает путь к документу из текущего окна.

  • Если запускаемое приложение требует только путь к каталогу (как в случае с Super + Shift + Q), то путь урезается до пути к каталогу.
  • В ином случае используется полный путь.

Частные примеры действий, которые становятся вам доступны c использованием данных возможностей:

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

Таким образом ваша работа с документами перестаёт быть приложение-центричной и становится документо-центричной. В фокусе вашего внимания то, С ЧЕМ вы работаете, а не то, КАКИМИ ПРИЛОЖЕНИЯМИ вы работаете. Вы легко можете «перекинуть» один и тот же файл/объект/документ в другое приложение просто нажав хоткей. DE видит и понимает контекст вашей работы.

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

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

 ,

wandrien
()

Тест китайского CPU в составе китайского ПК (Loongson)

Форум — Talks

Сабж: https://www.youtube.com/watch?v=ahbhydZSF2c

CPU LS3A6000, 4 ядра, 8 потоков, 2.0-2.5 ГГц, L3 16 МБ

TLDR:

  1. Автор видео сравнивал производительность с 12600K. Если для 12600K выставить аналогичные число ядер и максимальную частоту, то он всё равно оказывается быстрее, чем 3A6000.
  2. Сетевая карта аппаратно отвалилась прямо во время тестов.
  3. Дискретная видеокарта не запускается.
  4. Если использовать больше двух устройств USB, у автора начинала глючить мышь.

 ,

wandrien
()

Будущее личных вычислительных систем

Форум — Talks

Хочу рассказать о своём видении некоторой «ментальной модели» – того, как пользователь настоящего и будущего выстраивает и будет выстраивать взаимодействие с программной средой.

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

У пользователя запросто может быть во владении пара смартфонов, планшет, пара ноутбуков, один жирный десктоп, пара крупных мониторов, да еще умный телевизор в полстены.

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

Весь этот зоопарк устройств обусловлен спектром ФИЗИЧЕСКИХ различий. Что-то экономичное и компактное, что-то большое и мощное, а что-то привязано к конкретному рабочем месту – под физически разные контексты необходимы физически разные устройства, что обусловлено объективными ограничениями нашего материального мира и доступных нам технологий.

А вот голова у пользователя – одна. И в этой голове совсем нет необходимости, и одни только проблемы от того, что у вас есть, скажем, восемь разных «мест», в которых лежат разные данные, установлены разные программы, выполнен вход в разные сервисы, применены различные персональные настройки и так далее.

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

Вот этот «перенос данных в облака» — он как раз про это — про то, чтобы отвязать ваше личное информационное пространство от физической коробки.

Но я хочу поговорить не про корпоративные попытки сделать вас рабом системы, которая хранит все ваши данные на своих серверах. А про что-то противоположное.


Итак, у моих данных есть некоторый «дом по умолчанию». В моём случае это ноутбук. Это решение сегодняшнего дня, но оно меня устраивает не всецело. В идеале, таким решением должен быть смартфон как более компактный и лёгкий девайс.

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

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

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

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

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


То же самое верно при временном использовании устройств. Если я прихожу на работу или к подруге, то я достаточно доверяю им, чтобы с их устройства работать со своими данными (а все мои данные — на смартфоне), но не достаточно доверяю, чтобы они имели доступ к моим данным в моё отсутствие.

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

А как было сказано выше — между моим ноутбуком и смартфоном не должно быть никакой разницы. Следовательно, я работаю с чужой машины точно так же, как если бы я сидел дома за своим ноутбуком.


Всё вышеописанное вполне естественным образом ведёт нас к peer-2-peer структуре. Не той, которая «противостоит цензуре и за свободу информации», а сугубо практической её стороне — упрощение управления зоопарком машин, снижение затрат на их администрирование, на управление личными данными.

В такой модели «владение данными» и «обработка данных» отвязаны от «владения железом» и от административных издержек, с ним связанных.

Также такой подход можно назвать термином Zero Effort, который я придумал только что. Суть этого подхода состоит в том, что мы решительно устраняем любые издержки на какой-либо процесс… концептуально меняя парадигму софта и работы с ним. То самое: «Идеальный прибор — когда прибора нет, а функции его выполняются.»

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

  • ZeroInstall — децентрализованная кросс-платформенная система инсталляции софта, отвязанная от операционной системы (но способная использовать общесистемный кэш артефактов при соответствующей настройке). Флатпак здорового человека, если бы его делали не архитектурные астронавты.
  • ZeroNet — децентрализованная система доставки и исполнения веб-сайтов и веб-приложений.
  • IPFS — децентрализованная система доставки файлов по хэш-суммам.
  • syncthing — децентрализованное средство прозрачной синхронизации файлов между машинами.

Каждое из этих решений вполне подходит под концепцию Zero Effort:

  • ZeroInstall устраняют издержки на обслуживание пакетной базы операционной системы, устраняя идею общесистемной пакетной базы.
  • ZeroNet и IPFS устраняют издержки на обслуживание хостинга путём уничтожения понятия хостинга как самостоятельной единицы, необходимой для функционирования веб-сайта.
  • syncthing устраняет издержки на обслуживание физически разных носителей, делая их физически разнесёнными зеркалами одного виртуального носителя.

P.S.

4 указанных примера на мой взгляд являются реальными инновациями и движением вперёд согласно духу времени и потребностям людей. А вот изобретение очередной оконной системы, звукового сервера и переписывание очередной библиотеки на Раст — никак таковыми не являются.

syncthing был реализован на Go, и это никак ему не помешало.

 , , ,

wandrien
()

Об особенностях учёта потребления памяти

Форум — General

Ситуация:

Была запущена opera, которая жрёт 6 гигов, + была запущена игруля. В результате система вытеснила Оперу и всё ненужное в своп. Теперь закрываем игрулю, а затем закрываем Оперу.

Остаётся вот такая картина:

vadim@aquila:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15906        1647       13367         711        1915       14259
Swap:           8191        4887        3304

Как видно, занято 4887 метров в свопе. Я уже знаю, что это течёт моя программа, но суть тут в том, что смотрим как работает учёт потребления памяти. Вырубаем своп:

vadim@aquila:~$ sudo swapoff -a
[sudo] пароль для vadim: 
vadim@aquila:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15906        6511        8494        5139        6351        9395
Swap:              0           0           0

Теперь вся утёкшая память загружена из свопа обратно в ОЗУ. И она, внезапно, в секции shared. И при этом она же — в секции «buff/cache»! А вот это неожиданно.

Смотрим разницу показателей, цифры бьются логично:

buff/cache 6351 - 1915 =  4436
shared     5139 - 711  =  4428
used       6511 - 1647 =  4864
swap used  0    - 4887 = -4887

Теперь смотрим htop:

https://ibb.co/QYqJGbG

И как видно, в htop нет большого объёма «buff/cache». Он понимает, что «buff/cache» и shared дублируют друг друга.

И также видно, что утёкшая память не отображается ни в RESIDENT, ни в SHARED, ни даже в VIRTUAL ни одного процесса. Она есть, она учитывается системой как занятая, но её нет в счётчиках показателей потребления памяти процессов.

Теперь убиваем виновника:

vadim@aquila:~$ killall stuurman-desktop
vadim@aquila:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15906        1782       13214         442        1663       14124
Swap:              0           0           0

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

buff/cache 6351 - 1663 = 4688
shared     5139 - 442  = 4697
used       6511 - 1782 = 4729

Итак, пока только один вывод:

  • Реальное потребление памяти процессом может быть никак не связано с числами, которые htop показывает для процесса.

И остались открытые вопросы:

  1. Что именно показывает free и что именно показывает htop для общесистемных показателей. Придётся заглянуть в код, чтобы узнать точно.
  2. Как при таких условиях искать источник большого потребления ОЗУ в случае, если у нас нет возможности убивать все подозреваемые процессы подряд.
  3. А, ну и чуть не забыл. Надо всё-таки найти и исправить утечку в моём коде… когда-нибудь уже.

 , , ,

wandrien
()

Новый диалог открытия файлов GNOME

Форум — Talks

Разработчики GNOME подвели итоги работы, проведённой в проекте за последнюю неделю. Мэйнтейнер файлового менеджера Nautilus (GNOME Files) опубликовал планы по созданию реализации интерфейса выбора файлов (Nautilus.org.freedesktop.impl.portal.FileChooser), который может применяться в приложениях вместо диалогов открытия файлов, предоставляемых GTK (GtkFileChooserDialog). По сравнению с реализацией из GTK в новом интерфейсе будет обеспечено более близкое к GNOME поведение и визуальное оформление, а также будут задействованы элементы и расширенные возможности платформы GNOME, такие как libadwaita и пометка избранных файлов звёздочкой.

(Источник: https://www.opennet.ru/opennews/art.shtml?num=60939)

Картинко: https://thisweek.gnome.org/posts/2024/04/twig-142/0986a0a3dabcb41da5823158529d99e3bc6044811776317521763237888.png

  1. Хорошая новость: Гном наконец-то понял, что диалог открытия файлов должен делаться на основе файлового менеджера. На это ушло всего… 27 лет.
  2. Плохая новость: теперь диалог открытия файлов будет тормозить так же как весь Наутилус.

 , , ,

wandrien
()

Minimal 64x4: 8-битный компьютер на чипах 74xx серии, без микропроцессора

Форум — Talks

Автор пишет, что компьютер по производительности в 4 раза превосходит Commodore C64 и Apple II.

 , , ,

wandrien
()

Как поживает ReactOS в 2024 году

Форум — Talks

Сабж: https://www.youtube.com/watch?v=E-VDF85F-XY

TLDR:

  • Реальные приложения либо не запускаются, либо не работают, либо роняют систему.
  • Система в любой момент готова свалиться с ошибками даже в виртуалке.
  • На реальном железе у автора видео не запустился даже установщик.

Собственно, за 2 или 3 года с тех пор, как я писал о том, что ReactOS некому разрабатывать, ничего не изменилось.

Ядро и критичные системные компоненты нуждаются в существенных доработках и исправлении багов. Заниматься этим некому. Та малая часть коммитов, которая по коммит логу идёт в ntoskrnl и другие критичные вещи — это капля в море.

А пока система не научится не падать хотя бы в виртуалке, привлечь более широкий круг к разработке не получится.

 ,

wandrien
()

Всё еще торт

Форум — Talks

@Irma и @thesis имеют наилучшее чувство юмора на ЛОРе.

Их можно читать вместо почивших квотезов.

 

wandrien
()

Моё видение важных фич, в настоящее время отсутствующих в экосистеме СПО

Форум — Development

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

Интероперабельность по файловым системам между разными ОС

Реализация полной поддержки ext4 для ядер FreeBSD, NetBSD и ReactOS/NT.

Реализация полной поддержки UFS/FFS для ядер Linux и ReactOS/NT.

Реорганизация исходного кода glibc и вынос оттуда логики сервисов в демоны

Известная особенность, что glibc не может быть собрана полностью статически, поскольку завязана на модульный механизм, связанный с загрузкой произвольного набора *.so, предоставленных другими компонентами ОС.

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

Это позволит собирать программы полностью статически, при этом гибко используя любые фичи ОС, предоставленные этим модульным механизмом. (А на него много чего завязано, от резолвинга DNS, до перечисления юзеров в системе.) А также улучшит интероперабельность между дистрибутивами.

Это позволит также использовать полный набор фич, предоставленных механизм Name Service Switch, для приложений, которые вообще не используют glibc.

Универсальный формат бинарника для запуска на разных ОС и универсальное ABI, отвязанное от конкретного ядра

То, что универсальный формат бинарника, запускающийся на самых разных ядрах, в принципе возможен – доказал проект cosmopolitan libc.

Однако этот проект имеет недостатки:

  • Для главной разработчицы всё это какая-то игрушка, разработка ведётся без конкретных целей и задач. Иными словами, я такой разработчице не доверяю. Нужен кто-то более серьёзный, если закладываться на проект как на важный инфраструктурный элемент.
  • Проект ставит целью сборку только полностью статических бинарников, таким образом ABI в них отсутствует. Хотелось бы видеть ОС-независимую реализацию модульной экосистемы, с возможностью грузить *.so точно так же, как это делается в обычных ОС.

В идеале хотелось бы видеть тулчейн, который способен собрать стек библиотек начиная от базовых и вплоть до графических тулкитов, и при этом получившийся набор библиотек способен работать поверх Linux, FreeBSD, NetBSD – как минимум.

Я полагаю, в 2024-м вполне осмысленно ставить такого рода задачу, а не складывать все яйца в одну корзину и не закладываться на одно единственное ядро.

Применение pacman и makepkg для дистрибутивов с фиксированным релиз-циклом

Из всего зоопарка пакетных менеджеров, по моему опыту самым беспроблемным в эксплуатации является pacman и лёгким для создания пакетов. Хотелось бы видеть на нём действительно разные ОС с разным подходом к релиз циклу, а не просто респины Арча.

Было бы интересно увидеть мета-дистрибутив, который объединяет все перечисленные наработки, предоставляя возможность использовать ядра Linux/FreeBSD/NetBSD и при этом имея прикладное ABI, отвязанное от ABI ядра.

 , , ,

wandrien
()

RSS подписка на новые темы