Неплохо. Но:
1) "~/rpmbuils/SOURCES" — здесь опечатка
2) ни разу не встречал патчей с наименованием пакет-версия-rosa-описание.patch. Обычно без "rosa"
3) включать название и версию пакета в имя патча — я считаю, очень контрпродуктивно. Народ тратит время и силы на "красивое" наименование патчей, а сил написать описание патча, что и зачем он делает, — не остается. При обновлении версии из-за переименований файла часто едет история git.
В списке патчей эти лишние буквы мешают сразу видеть суть патча по названию файла, особенно, когда такое длинное название куда-нибудь не влезает по ширине и обрезается середина имени файла. Пример: https://abf.io/import/systemd/tree/rosa2016.1 На какой бы черт может понадобиться назвать всю кучу патчей вместо 000N-суть-патча.patch systemd-230-rosa-000N-суть-патча.patch?
Единственное удобство от такой схемы, которое смог придумать, — это когда вместо работы с git с файлами пакетами в отдельной директории все от множества пакетов свалено в ~/rpmbuild/SOURCES и могут быть файлы от разных пакетов с одинаковым названием.
"Я просто установлю по паре каждой ОС и попрошу наименее занятых бухов по полчаса-час попользоваться. Что скажут — от того и будем плясать, наверное."
Это очень большая ошибка новичков. Ставьте то, где интерфейс минималистичен, то есть меньше возможностей "нажать не туда", который реализует привычную парадигму рабочего стола, управления окнами и пр. и при этом имеет необходимый функционал. Лучше всего с этим справляется XFCE с меню Whisker. Но можно и LXQt, и МАТЕ.
У пользователей не нужно ничего спрашивать.
Люблю Ubuntu за возможность выбора: хочу делать по-нормальному и в удобном для поддержания на множестве машин виде — собираю пакеты в свой PPA, а хочу быстрое готовое решение — ставлю snap. Еще нравится acestreamplayer от vasilisc в качестве примера, где snap уместен — лютая проприетарщина с очень развесистой цепочкой зависимостей. Такому самое место иметь защиту AppArmor от snapd из коробки.
snap хорошо решает конкретную задачу — контейнер приложения с зависимостями, flatpak же устроил параллельную пакетную систему, мейнтейнеры флатпака тоже иногда ломают голову, а почему же приложение не собирается с glibc из Flatpak SDK.
Встаю в очередь. Очень хочу планшет на линуксе, с открытыми спеками и сборно-разобрный. На Chuwi Hi12 GNU/Linux неплохо работал (работало все, кроме говнокамер), но чувик отбросил коньки спустя год.
Вроде бы в FreeBSD 12.0-CURRENT портировали из линукса работу с этими видеокартами. Но таки да, все весьма плохо. У меня вот Radeon HD8400 RS (интегрированная) в линуксе прекрасно работает на свободном amdgpu из коробки, а во фре — нет.
На новых видеокартах даже nouveau толком не работает, потому что зеленые факеры не публикуют firmware, а без нее невозможно, как минимум, увеличение частоты видеокарты с минимальной по умолчанию.
Вы странные люди. На linux.org.ru, opennet.ru и здесь, на Хабре, просили присылать вам неправильно открывающиеся у вас документы на support@onlyoffice.com. Присылал docx — в ответ была отписка, что поддержка некоммерческой версии не осуществляется, присылал odt — что это не основной формат. И так раза 3 минимум, после чего забил что-либо присылать. На files@ есть смысл присылать..?
Были. И свопа тоже не было. После описанного в статье (zram, swap на диске, vm.admin_reserve_kbytes) в целом исчезли или стали проявляться крайне редко, а Alt+SysRq+F спасает, когда нужно.
Неплохо. Но:
1) "~/rpmbuils/SOURCES" — здесь опечатка
2) ни разу не встречал патчей с наименованием пакет-версия-rosa-описание.patch. Обычно без "rosa"
3) включать название и версию пакета в имя патча — я считаю, очень контрпродуктивно. Народ тратит время и силы на "красивое" наименование патчей, а сил написать описание патча, что и зачем он делает, — не остается. При обновлении версии из-за переименований файла часто едет история git.
В списке патчей эти лишние буквы мешают сразу видеть суть патча по названию файла, особенно, когда такое длинное название куда-нибудь не влезает по ширине и обрезается середина имени файла. Пример: https://abf.io/import/systemd/tree/rosa2016.1 На какой бы черт может понадобиться назвать всю кучу патчей вместо 000N-суть-патча.patch systemd-230-rosa-000N-суть-патча.patch?
Единственное удобство от такой схемы, которое смог придумать, — это когда вместо работы с git с файлами пакетами в отдельной директории все от множества пакетов свалено в ~/rpmbuild/SOURCES и могут быть файлы от разных пакетов с одинаковым названием.
Не стоит! Сделайте в своей ветке , где N — кол-во ваших коммитов, затем все патчи приложите к пакету:
Patch1: 0001-xxx.patchPatch2: 0002-xxx.patch
<...>
%prep
%setup
%apply_patches
Это позволит сразу четко видеть, какие правки были сделаны относительно апстрима.
Так тоже не надо делать. Если хотите все же прямо из git собирать, то укажите дерево конкретного коммита, чтобы, когда вы сделаете новые коммиты, используемые при сборке исходники не изменились. Пример: abf.io/import/realmd/blob/890302de0d7d9518781aee834afd325ce5c3e046/realmd.spec
И заявлено исправление: wiki.astralinux.ru/pages/viewpage.action?pageId=53644505
В качестве источника в БДУ указана эта статья. Интересно, пытался ли автор статьи сообщить об уязвимости какими-либо другими способами.
"Я просто установлю по паре каждой ОС и попрошу наименее занятых бухов по полчаса-час попользоваться. Что скажут — от того и будем плясать, наверное."
Это очень большая ошибка новичков. Ставьте то, где интерфейс минималистичен, то есть меньше возможностей "нажать не туда", который реализует привычную парадигму рабочего стола, управления окнами и пр. и при этом имеет необходимый функционал. Лучше всего с этим справляется XFCE с меню Whisker. Но можно и LXQt, и МАТЕ.
У пользователей не нужно ничего спрашивать.
snap хорошо решает конкретную задачу — контейнер приложения с зависимостями, flatpak же устроил параллельную пакетную систему, мейнтейнеры флатпака тоже иногда ломают голову, а почему же приложение не собирается с glibc из Flatpak SDK.
Пора учиться ужнавать друг друга по аватарке, наш мир тесен.
https://github.com/kernins/linux-chwhi12/tree/master/configs/audio в /usr/share/alsa/ucm и es8316.c из https://github.com/kernins/linux-chwhi12/tree/master/sound/soc/codecs в исходниках ядер 4.15 заменял.
На новых видеокартах даже nouveau толком не работает, потому что зеленые факеры не публикуют firmware, а без нее невозможно, как минимум, увеличение частоты видеокарты с минимальной по умолчанию.
sudo apt install intel-microcodesudo apt install intel-micrododeИ все дальше само автоматически без вашего участия.
На линуксе микрокод процессора обновляется средствами ОС и из репозитория. Несколько дней назад в ведущих дистрибутивах обновился.
Вы странные люди. На linux.org.ru, opennet.ru и здесь, на Хабре, просили присылать вам неправильно открывающиеся у вас документы на support@onlyoffice.com. Присылал docx — в ответ была отписка, что поддержка некоммерческой версии не осуществляется, присылал odt — что это не основной формат. И так раза 3 минимум, после чего забил что-либо присылать. На files@ есть смысл присылать..?
А, ну вот, решаете сами, а лучше бы читали переменные окружения, как умеет делать Qt.
Аналогичная проблема. Планшет Chuwi Hi12, экран HiDPI 2K, KDE, Ubuntu 17.10, в настройках KDE нецелочисленное масштабирование, допустим, 1.8. Onlyoffice открывается маленьким окном. Chromium, Qt5 масштабируются правильно.