TechrooM

Если все это время Вас смущало прослушивание любимых треков через браузер, используя сервис Яндекс Музыка, то есть выход — это нативное приложение если быть точнее пересборка с использованием Electron, а значит есть нюансы. :D Страница проекта на GitHub: github.com/...nux Страница для загрузки готовых пакетов: github.com/...ses P. S. Есть нюанс он заключается в том, что после запуска приложения модная переливающаяся заставка нагружает GPU на 30%, в моем случае это GTX 1050 Ti, и поглощает 175 Мб видеопамяти, но как только вы уходите из главного меню например в коллекции нагрузка тут же падает практически до нуля. Владельцы встроенных GPU, не пугайтесь, если словите фризы или сильную просадку батареи при прослушивании «Моя волна» с развернутым окном. Хорошо, что хоть в свернутом состоянии такого поведения нет. Всем приятного прослушивая и длинных плейлистов. Запускал версию: 5.42.0

BioShock Infinite фризы, тормоза под Linux и на SteamDeck Если на Вас напала ностальгия, но непонятные фризы и тормоза портят при повторном прохождении(а может и нет) BioShock Infinite, то вот решение: 1. Переходим в папку с игрой, у меня на LinuxMin 20.04 это /home/<username>/.local/share/Steam/steamapps/common/BioShock Infinite 2. Находим файл конфигурации он лежит по адресу BioShock Infinite/Engine/Config/BaseEngine.ini 3. В разделе [TextureStreaming] находим строчку PoolSize= где устанавливаем значение в зависимости от размера видеопамяти, примерно такое соотношение PoolSize 1200 = VRAM usage = 1800 PoolSize 1400 = VRAM usage = 2000 PoolSize 1600 = VRAM usage = 2200 PoolSize 1800 = VRAM usage = 2400 PoolSize 2000 = VRAM usage = 2600 PoolSize 2200 = VRAM usage = 140 Установил 2000 для GTX1050Ti полет нормальный, 90% фризов пропало, только в начале уровня чуть есть, в остальном все нормально. Драйвер видеокарты: 565.77

A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: Данная ошибка возникает когда в репозиториях дистрибутива и у сторонних поставщиков обновились ключи GPG с помощью которых осуществляется подпись .deb пакетов, по которой apt-get, aptitude или иной пакетный менеджер проверяет достоверность пакета, что он не подложный. И как-то так сложилось, что нет до сих пор механизма уведомления пользователей (либо мне неизвестен) о смене ключей в репозитории кроме как вот такой не сильно лицеприятной ошибке. Чтобы устранить данный недуг мы либо руками заново добавляем все ключи через команду: gpg --keyserver kkeyserver.ubuntu.com--recv-keys 16126D3A3E5C1192 где 16126D3A3E5C1192 необходимо заменить на номер сигнатуры из ошибки. А если репозиториев 20 или 30-ть? Тут на помощь приходит вариант автоматического обновления всех ключей через команду: apt-key adv --refresh-keys --keyserver keysekeyserver.ubuntu.com При условии что все ключи что используются размещены на сервере ubunt'ы.

Switch case против If Else: Интересный факт Мы часто используем if-else или switch case создавая различные проверяющие выражения. Но знали ли вы что в condition check из двух условных операторов switch case более эффективный? Для switch-case проверяет выражение basically branch table или бинарный поиск (O(log n)), для if-else каждое условие проверяется одно за другим пока не получим true. switch(variable){ // } Когда switch-case используется подобны образом поток выполнения переходит в точку где variable имеет значение true и исключает иные проверки, но для маленького числа проверок разница между switch-case и if-else минимальна. Но что более важно switch-case лучше читается и его применение поощряется там где это возможно в отличии от if-else. П.С. В надуманном примере где используется вариант if ( i == n) {} else if (){} else ... где 0 < n < 100 выигрыша между switch case и if-else нет время выполнения идентично, при росте количества выражений сравнения до 1000 switch-case заметно проигрывает именно из-за O(log n) Оригинал hclck.ru/...amn