Ладно, понял, что приведённая мной инструкция специфична для инфраструктуры арча, и на Manjaro хоть и можно её повторить, но полученный пакет может оказаться более новой версии, чем поставляемый в репах Manjaro. Однако если сделать asp checkout, переключиться git checkout на нужную версию и собрать через makepkg, то должен получиться пакет, идентичный установленному из репозиториев.
lts ядра manjaro скачиваются как блобы с kernel.org
Только сейчас понял, что на kernel.org вроде как вообще не хостятся предсобранные версии ядер, только исходники. Manjaro действительно не собирают пакеты из исходников, но они клонируют уже собранные пакеты из репозиториев Arch Linux.
Как в манжаре пересобрать ядро, идентичное установленному, за исключением одного флага(я задаю вопрос из любопытства)?
Я тут рядом уже писал про то, как это делается на примере openvpn, с ядром всё то же самое, только править скорее всего придётся не PKGBUILD, а config.
А если вдруг что-то настолько специфичное, что нет даже в aur, либо нужна конкретная версия или нестандартная конфигурация, то без проблем пишется свой PKGBUILD или правится лежащий в AUR/репозиториях.
Вообще, Wayland на десктопе приятен, например, тем, что под ним тот же GNOME запускается ощутимо быстрее, чем под иксами, а в консоли можно удобно (по сравнению с xclip) пользоваться буфером обмена при помощи wl-copy/wl-paste.
Мне ещё очень нравится, как работают дробные коэфициенты масштабирования для мониторов (с gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']").
в некоторых приложениях были какие-то лютые тормоза отрисовки (например в telegram)
Qt-приложения (например, telegram) в Gnome по умолчанию запускаются в XWayland. Можно заставить использовать Wayland переменной QT_QPA_PLATFORM=wayland, но это обычно сопровождается всякими артефактами отображения (на данный момент в моей системе это увеличенный вдвое курсор).
шаринг экрана в скайпах-зумах — не работает совсем
Я иногда смотрю, чтобы иметь хоть какое-то представление о том, каких стоит ожидать изменений в связанных с ковидом ограничениях.
И, кстати, с этой точки зрения возможно не так и важна достоверность этой статистики.
Я не видел партнёрского соглашения твича, но есть ощущение, что абсолютное большинство стримеров-партнёров выкладывают записи на ютуб, при этом банов никому за это не прилетало.
Пока читал обсуждение приведённого в статье пропоузала в Nim, его закрыли с комментарием, что новый рантайм доступен в 1.4 :)
А для многих случаев семантика владения и перемещения, как я понимаю, доступна уже с 1.2 и --gc:arc.
Не совсем так, раньше тоже хранились наносекунды, и счётчик был 64-битным. Только в нём 32 бита было отведено на секунды и 32 на наносекунды, а теперь со включенным bigtime это будет просто 64-битный беззнаковый счётчик наносекунд с 1901-го года.
Всё верно, насколько могу судить по содержимому патча, раньше xfs timestamp включал 32-битный Unix timestamp + 32 бита на наносекунды, а с новой фичей — просто 64-битный счётчик наносекунд.
Для вызова многопоточной версии необходимо, чтобы был подключен файл tbb/tbb.h при компиляции на платформе Intel.
Что подразумевается под платформой Intel? TBB работает независимо от производителя CPU и даже архитектуры (по крайней мере на ARM точно всё работает как надо).
Кстати, в большинстве дистрибутивов Linux для него есть предсобранные пакеты.
Ладно, понял, что приведённая мной инструкция специфична для инфраструктуры арча, и на Manjaro хоть и можно её повторить, но полученный пакет может оказаться более новой версии, чем поставляемый в репах Manjaro. Однако если сделать
asp checkout, переключитьсяgit checkoutна нужную версию и собрать черезmakepkg, то должен получиться пакет, идентичный установленному из репозиториев.Только сейчас понял, что на kernel.org вроде как вообще не хостятся предсобранные версии ядер, только исходники. Manjaro действительно не собирают пакеты из исходников, но они клонируют уже собранные пакеты из репозиториев Arch Linux.
В арче с kernel.org скачиваются сорцы, а репы манжары вроде как просто снапшотами арчовых являются, так что по идее всё так же должно быть.
Это же какой-то синтетический тест неопределённой сложности, а не реальные игры.
Я тут рядом уже писал про то, как это делается на примере openvpn, с ядром всё то же самое, только править скорее всего придётся не
PKGBUILD, аconfig.А мне уже перестало хватать, недавно купил карточку на 256Гб для своей коллекции музыки.
В 1Тб+ пока в ближайшие годы лично для себя смысла не вижу, но всё же согласен, хорошо, что они уже есть и прогресс идёт ещё дальше.
До сих пор пользуюсь флешкой на 65Мб. А чего, вещь нужная довольно редко, и чаще всего для передачи каких-нибудь документов, хватает с лихвой.
С этим багом не сталкивался, но в целом в подобных случаях самостоятельная сборка пакета в арче сводится к
Конечно, обновлять собранный таким образом пакет придётся самостоятельно, но это всё-таки исключительные случаи обычно.
А если вдруг что-то настолько специфичное, что нет даже в aur, либо нужна конкретная версия или нестандартная конфигурация, то без проблем пишется свой PKGBUILD или правится лежащий в AUR/репозиториях.
Мне ещё очень нравится, как работают дробные коэфициенты масштабирования для мониторов (с
gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']").Qt-приложения (например, telegram) в Gnome по умолчанию запускаются в XWayland. Можно заставить использовать Wayland переменной
QT_QPA_PLATFORM=wayland, но это обычно сопровождается всякими артефактами отображения (на данный момент в моей системе это увеличенный вдвое курсор).У меня в Google Meet работает.
Я иногда смотрю, чтобы иметь хоть какое-то представление о том, каких стоит ожидать изменений в связанных с ковидом ограничениях.
И, кстати, с этой точки зрения возможно не так и важна достоверность этой статистики.
Я не видел партнёрского соглашения твича, но есть ощущение, что абсолютное большинство стримеров-партнёров выкладывают записи на ютуб, при этом банов никому за это не прилетало.
Пока читал обсуждение приведённого в статье пропоузала в Nim, его закрыли с комментарием, что новый рантайм доступен в 1.4 :)
А для многих случаев семантика владения и перемещения, как я понимаю, доступна уже с 1.2 и
--gc:arc.Тем не менее в массовой и утилитарной ext4 тоже времена в наносекундах хранятся. Видимо достаточно частое требование.
Для совместимости же (с Unix timestamp и своими же старыми).
32-битный Unix timestamp позволяет хранить даты с 13 декабря 1901 по 19 января 2038.
Не совсем так, раньше тоже хранились наносекунды, и счётчик был 64-битным. Только в нём 32 бита было отведено на секунды и 32 на наносекунды, а теперь со включенным bigtime это будет просто 64-битный беззнаковый счётчик наносекунд с 1901-го года.
Кстати, я что-то пропустил и XFS уже де-факто стандартная ФС на всех Linux-системах или заголовок и первый абзац вводят в заблуждение?
Всё верно, насколько могу судить по содержимому патча, раньше xfs timestamp включал 32-битный Unix timestamp + 32 бита на наносекунды, а с новой фичей — просто 64-битный счётчик наносекунд.
Я сам не проверял, но в статье речь идёт о GCC, а не отдельно libstdc++, да и здесь эта фича тестируется с g++ из GCC 9.1, а не icc.
Что подразумевается под платформой Intel? TBB работает независимо от производителя CPU и даже архитектуры (по крайней мере на ARM точно всё работает как надо).
Кстати, в большинстве дистрибутивов Linux для него есть предсобранные пакеты.