Что на ПК (https://linux-hardware.org/?probe=fd350b52da, Chromium/Firefox), что на смартфоне (Fennec F-Droid) комментарии работают тормознуто. Например, сейчас ПК немного нагружен, например, открытым дико тормозным vk.com, несколько секунд ждал прогрузки комментариев, когда докрутил до них. FPS в форме комментария, в которую пишу прямо сейчас, низкий. Раньше такой фигни не было, работало быстро, ыбло приятно пользоваться, теперь - нет, отвратительно даже.
Щито?! Просто установки пакета wine или wine-stable на rosa2021.1 (Fresh/Chrome 12) достаточно, 32 битное окружение работает.
$ rpm -qa wine*
wine32-stable-6.0.1-5.i686
wine-stable-6.0.1-5.i686
wine-stable-binfmt-6.0.1-5.i686
$ WINEPREFIX=~/.wine-test wineboot
<...>
$ ls ~/.wine-test/drive_c -1v
ProgramData
'Program Files'
users
windows
Что пакеты wine от Fedora 34 заработали, забавно, но когда-нибудь могут и перестать работать.
Вы бы хоть спросили на support@rosalinux.ru или в t.me/rosalinux, раз что-то не получилось, прежде чем в почти официальную инструкцию писать вредные советы.
Для реализации работы приложений мы наладили контакт с ребятами из компании Etersoft
Посыл автора в том, что некто пришел в коллектив, где у большинства людей Linux, и потребовал, чтобы за него другие люди сделали работу по адаптации системы под его нестандартное окружение. Думаю, если вы сами у себя все наладите, вопросов не возникнет.
Это был скорее риторический вопрос к автору комментария, который написал, что, если не пользуешься vim, то значит мало пользуешься линуксом. Вот стало интересно, когда ждать постигания дзена.
А зачем? Для консольного редактирования устраивает nano, концепция комбинаций клавиш в нем нравится и весьма удобна, а на десктопе удобнее пользоваться графическими редакторами для задействования предоставляемых мышью возможностей (выделение текста, быстрый перевод курсора в нужное место, использование буфера средней кнопки мыши и др.)
Единственное место, где vim более-менее необходим — это редактирование файлов со смартфона по SSH, в nano не очень удобно, но не критично, когда есть эмуляция клавиши Ctrl.
Древность устройства не повод не работать в современных ОС. в свободных драйверах на линуксе этот принцип выполняется в подавляющем большинстве случаев.
Не ясны причины таких показателей, либо это как-то объясняется с точки зрения архитектуры ФС, либо это неправильные показания соответствующих утилит. Понятно, что CoW, процессы в фоне, но не в 32 раза же…
Недавно надоел жутко высокий Load Average и очень низкая скорость работы MySQL на BTRFS с CoW. btrfs balance работал сутками, доводил сервер до почти неотзывчивого состояния и никак не мог завершиться. И это при том, что с самого начала использовал btrfsmaintenance для регулярных автоматических балансировок.
Нашел статью человека, который сравнил производительность MySQL на BTRFS, где в первом случае БД были на одном разделе с другими данными, в т.ч. системой, как в отдельном подтоме, так и нет, во втором — на отдельном разделе. На общем разделе была огромная (более чем в 10 раз) просадка производительности по сравнению с другими ФС, во втором случае просадка была совсем небольшой. Сейчас статью не получается найти заново.
К этому времени в связи с невозможностью нормально отбалансировать старый диск (HDD) уже решил все данные через btrfs send | btrfs receive перенести на второй диск такого же размера, затем отключив первый. Заодно решил вынести MySQL в отдельный раздел BTRFS. Стало работать намного быстрее.
Эта статья заставила задуматься: а как отследить, что именно записывает на диск btrfs и почему? Это, вероятно, поможет понять, почему такая просадка производительности при БД на одном разделе с системой.
Можно при вызове rpmbuild задавать свою %_sourcedir или %_topdir, пример: github.com/ONLYOFFICE/desktop-apps/blob/master/win-linux/package/linux/Makefile#L208
abf-console-client (https://abf.io/soft/abf-console-client) командой abf rpmbuild примерно это и делает: создает в /tmp/ отдельную временную папку, внутри которой создается структура, аналогичная ~/rpmbuild/. rpmbb/rpmbs из etersoft-build-utils (https://packages.altlinux.org/ru/sisyphus/srpms/etersoft-build-utils) делают похожее, но еще дополнительно работают с git. Плюс dpkg в том, что можно легко хранить спеки с исходниками вместе и спокойно собирать пакет из кода, когда как в RPM нельзя просто так так сделать и разные обвязки над RPM пытаются решить эту проблему, у gear+etersoft-build-utils это неплохо получается. Но зато в RPM более упорядоченная структура.
Я для сборок пакетов использую rootfs, запускаемую в контейнере: wiki.rosalab.ru/ru/index.php/Образ_rootfs
При сборке локально сборочное окружение грязное, в сборочнице с чистым окружением результат может быть другим, например, потому что части сборочных зависимостей не будет. mock-urpm как раз собирает в чистом чруте, многим кажется удобным.
Спасибо большое за статью! Прошло 8 лет, интересно, какова судьба применения дубаса?
Что на ПК (https://linux-hardware.org/?probe=fd350b52da, Chromium/Firefox), что на смартфоне (Fennec F-Droid) комментарии работают тормознуто. Например, сейчас ПК немного нагружен, например, открытым дико тормозным vk.com, несколько секунд ждал прогрузки комментариев, когда докрутил до них. FPS в форме комментария, в которую пишу прямо сейчас, низкий. Раньше такой фигни не было, работало быстро, ыбло приятно пользоваться, теперь - нет, отвратительно даже.
А где взять саму vmware для практики?
Спасибо
> автор задавал туда вопрос и на него никто не ответил
А можете ссылку на сообщение дать?
Нет, такого не было. https://abf.io/import/wine
Щито?! Просто установки пакета wine или wine-stable на rosa2021.1 (Fresh/Chrome 12) достаточно, 32 битное окружение работает.
Что пакеты wine от Fedora 34 заработали, забавно, но когда-нибудь могут и перестать работать.
Вы бы хоть спросили на support@rosalinux.ru или в t.me/rosalinux, раз что-то не получилось, прежде чем в почти официальную инструкцию писать вредные советы.
Молодцы!
Единственное место, где vim более-менее необходим — это редактирование файлов со смартфона по SSH, в nano не очень удобно, но не критично, когда есть эмуляция клавиши Ctrl.
Нашел статью человека, который сравнил производительность MySQL на BTRFS, где в первом случае БД были на одном разделе с другими данными, в т.ч. системой, как в отдельном подтоме, так и нет, во втором — на отдельном разделе. На общем разделе была огромная (более чем в 10 раз) просадка производительности по сравнению с другими ФС, во втором случае просадка была совсем небольшой. Сейчас статью не получается найти заново.
К этому времени в связи с невозможностью нормально отбалансировать старый диск (HDD) уже решил все данные через
btrfs send | btrfs receiveперенести на второй диск такого же размера, затем отключив первый. Заодно решил вынести MySQL в отдельный раздел BTRFS. Стало работать намного быстрее.Эта статья заставила задуматься: а как отследить, что именно записывает на диск btrfs и почему? Это, вероятно, поможет понять, почему такая просадка производительности при БД на одном разделе с системой.
abf-console-client (https://abf.io/soft/abf-console-client) командой abf rpmbuild примерно это и делает: создает в /tmp/ отдельную временную папку, внутри которой создается структура, аналогичная ~/rpmbuild/. rpmbb/rpmbs из etersoft-build-utils (https://packages.altlinux.org/ru/sisyphus/srpms/etersoft-build-utils) делают похожее, но еще дополнительно работают с git. Плюс dpkg в том, что можно легко хранить спеки с исходниками вместе и спокойно собирать пакет из кода, когда как в RPM нельзя просто так так сделать и разные обвязки над RPM пытаются решить эту проблему, у gear+etersoft-build-utils это неплохо получается. Но зато в RPM более упорядоченная структура.
Я для сборок пакетов использую rootfs, запускаемую в контейнере: wiki.rosalab.ru/ru/index.php/Образ_rootfs
При сборке локально сборочное окружение грязное, в сборочнице с чистым окружением результат может быть другим, например, потому что части сборочных зависимостей не будет. mock-urpm как раз собирает в чистом чруте, многим кажется удобным.