Может персонально qBittorrent заткнуть через Options > Advanced > Display program on-screen notifications

У меня наблюдается такой-же косяк с вводом букв другой раскладки при печати. Редко, примерно пару раз в неделю. Не вымораживает, привык. Вот то, что переключение раскладки бывает тупит, тут — да, дико бесит.

Появился данный баг как раз после обновления системы с 15.7 на 15.8 и так до сих пор и идет.

Есть вариант — gXNeur. Но как он себя на DDE покажет — я х.з. У меня под Ubuntu на Gnome и Cinnamon работал отвратительно.

Удалить то чем не пользуемся через терминал командой «sudo apt-get purge то-что-надо-удалить-списком-в-строчку-через-пробел».

Затем почистить ошметки командой «sudo apt-get autoremove»

Затем дотянуть с сети то, что могло отвалиться из зависисмостей командой «sudo apt-get install -f»

Обновить то чем пользуемся через терминал командой «sudo apt-get upgrade» и дождаться окончания процесса.

Жить спокойно…

Еще раз повторяю — компьютер с дипином и сервер с виндой на разных подсетях сидят. Если кого-то к кому-то «не подвинуть», то ничего работать не будет. Этим в автоматическом режиме занимается DNS сервер в сети, если он есть и правильно настроен на нужные подсети. Т.е. при вводе запроса доменного имени в строке запроса по типу smb://roga-and-kopiyta.com он (запрос) будет проходить через DNS сервер, на котором он узнает, что домену roga-and-kopiyta.com соответствует адрес в другой подсети 10.3.90.45 и пойдет прямиком туда. Если этого не сделать, то прямая долбежка напрямую по адресу 10.3.90.45 ничего не даст т.к. комп и сервер в разных подсетях находятся. По этому принципу работает сеть. Любая. Даже интернет.

Есть еще принцип — обращение напрямую по адресу. Это когда указывается запрос «smb://10.3.90.45» и он напрямую идет на адрес 10.3.90.45. В данном случае это не работает т.к. комп с дипином имеет адрес другой сети 10.3.25.29. Тут возможны три варианта.

1. Либо компу давать адрес из 90й подсети и идти напрямую на сервер
2. Либо компу оставить его родной адрес и добавить его интерфейсом в 90ю подсеть и идти напрямую на сервер.
3. Попробовать найти в 25й подсети этот же сервер, если он на ней есть и имеет такой адрес — 10.3.25.45. Т.е. сделать smbclient -L 10.3.90.45 и smbclient -L 10.3.25.45, и сравнить выхлоп на предмет соответствия. Если совпадет, то поздравляю — можно будет ходить на нужный сервер по адресу 10.3.25.45 и забыть об остальном (хоть это и не совсем правильно). Если выхлопа с 10.3.25.45 не будет и пингом он не отображается, то придется изгаляться с пунктами 1 и 2, но лучше спросить у админа доменное имя сервера и обрисовать ему ситуацию.  

По второму варианту можно посмотреть сюда…

Напиши — «Ребята, ставьте XFCE целиком». :))))))

У «xfce4-power-manager-plugins_1.4.4-4_amd64.deb» 22 зависимости — полноценный XFCE. :)))))

У вас, скорее всего, на LightDM при логине в систему появилась кнопка выбора DE в которую грузиться. 🙂

Эээм… «smb://20.2.25.25/Share», не?

Верить htop`у — он напрямую с железа показания снимает. А дипиновская хреновина — ненужная свистоперделка.

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

У меня на Lenovo Yoga 13 первого поколения аналогичная ситуация. Причем от версии дистрибутива данный глюк ни как не зависит. Проблема заключается в некорректной работе ядра линуха с контроллером питания на материнской плате — гасит питание на usb при переходе в спящий режим и не поднимает его при выходе из спящего режима. В интернетах находил патч для ядра, года три-четыре назад. Патч рабочий был, но загвоздка была в том, что патчить приходилось бы каждый раз каждое ядро при обновлении. Решил просто отказаться от использования спящего режима на ноуте.

Вам бы обоим проверить свои HDD для начала, на наличие бэд-блоков… Очень похожая симптоматика.

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

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

В данный момент на работе с подобным мучаюсь у одной машины на минте.

Подобное поведение получается вызвать искусственно лишь если в ручную передавать большой массив данных от 65-150 гигабайт по сети. При чем подкидыванием другой сетевой карты (с отключением интеграта), а также подменой системных дров сетевухи на вшитые в ядро — ни как не помогает, лишь увеличивает/уменьшает возможность передачи определенного объема данных. Смена ядер эффекта не дает. Проц, хард, память не причем — они оттестированы и замучены синтетическими тестами, а также стресс тестами в первую очередь, и которые они все успешно прошли циклами по 12/24/48 часов. Проблему получилось вызвать искусственно лишь попытками нагрузки на сетевой адаптер, а в следствии и на южный мост. В общем перетряхнул все — пришел к выводу, что южному мосту конец.