Те, кто пользовался Lubuntu и прочими gtk-based дистрибутивами на ноутбуке - наверняка встречались со следующей проблемой: когда компьютер тормозит (а для слабого нетбука это зачастую норма) - жесты тачпада для прокрутки работают не очень удобно и отзывчиво, иногда это "не очень" настолько не очень, что хочется совершить деструктивные действия с виновником торжества (с нетбуком-ли, с вызывающим тормоза процессом - зависит от ситуации). Под Windows я в таких случаях обычно прекращаю пользоваться жестами и просто тыркаю курсором по кнопочкам со стрелками на скроллбаре.

Увы, в gtk2 в некоторых темах оформления эти кнопки убрали, а в gtk3 это стало мейнстримом. Лечится просто: находим в домашнем каталоге файл ~/.config/gtk-3.0/gtk.css и добавляем там в конец файла (вне комментариев!) такую вот секцию:

.scrollbar {
-GtkScrollbar-has-backward-stepper: 1;
-GtkScrollbar-has-forward-stepper: 1;
-GtkRange-slider-width: 15;
-GtkRange-stepper-size: 20;
}

Если файла нет - создаём. Сохраняем, по необходимости перезапускаемся, радуемся жизни :). Для gtk2-приложений в принципе достаточно выбрать имеющую эти кнопки тему типа Clearlooks.

Переключать темы можно чем-нибудь типа gtk-chtheme или lxappearance.


UPDATE:

В последней версии Lubuntu данный финт ушами не работает. Однако в причинах не разбирался, поскольку в репозиториях имеется пакет clearlooks-phenix-theme, после установки которого и переключения на данную тему - полосы прокрутки возвращаются в нормальный вид. Живительные свойства этого пакета базируются на том простом факте, что эта тема доработана под gtk3, в то время как большинство тем в репозиториях до сих пор остались во временах gtk2.

Этот пост о бубне,но не о серверной. Это пост о Страуструпе, С++ и локалях-фасетах.

Не было у админа проблем, решил админ нормально изучить C++... ну, чтоб серьёзно, с STL, стандартными контейнерами, итераторами, вот это всё. Надо же писать нормально, а не на С классами... С++11\17 опять же...

Подозрение о том, что STL придумана инопланетным (т.е. не человеческим) разумом - закралось, естественно, довольно быстро. Но после ознакомления и интенсивных эротических приключений в попытках написать простенький кроссплатформенный Hello World, умеющий в кодировки - слов у меня уже нет, за исключением матерных. И я сейчас старательно пытаюсь перевести их на нормальный язык.

Мало того, что нормальной поддержки кодировок в STL в принципе нет, а то что есть - использовать можно только после подключения сторонних библиотек или самопального велосипеда. Мало того, что в C++11 вроде-бы двинулись в сторону нормальной реализации, но в C++17 эти нововведения объявят устаревшими и выкинут. Почему? Авторы стандарта говорят что идите на..фиг, вот почему, пользуйтесь сторонними библиотеками. Но это всё полная фигня, в конце концов можно написать велосипед или подключить ICU. Горю я по другой причине.

Основная беда в том, что STL придумал Страуструп. Я не знаю почему у рептилоидов (или кто он там) модно писать столь вычурные конструкции там, где хватило бы чего-то простого как кирпич. Я даже понимаю что универсальность и одинаковый подход к любому контейнеру или алгоритму - это в общем-то круто. И даже сама система локалей как контейнеров для фасетов, которые в свою очередь умеют всё то, что от локали требуется - вполне логична и правильна, пусть и слишком имхо раздута. Но... %?*%, почему нельзя было эту систему сделать так, чтобы она не зависела от платформы, от того как именно были собраны и слинкованы разные библиотеки... и самое главное - за каким хреном было завязывать идентификацию фасетов на значения статических, создаваемых при компиляции объектов. Наверное затем чтобы программа рандомно падала если часть id фасетов лежат в бинарнике программы, а другая часть в динамической библиотеке - не иначе. Именно это происходит при сборке динамических библиотек boost:locale с icu под windows.

Лечится - в моём случае помогла полностью статическая линковка. Полдня общения с гуглом дали два намёка что надо наоборот полностью отключить генерацию статических библиотек boost при сборке оного и тогда там случится что-то волшебное и динамические библиотеки тоже не будут путаться в id фасетов - пока не проверял, но возможно и это заработает, ибо в линуксе работает и при динамической линковке с boost.

Но когда-нибудь, хотя скорее это будет и никогда, но "никогда" - лишь значение итератора за последним элементом... В общем, если мне будет нечего делать - я напишу свою обёртку вокруг ICU, с... нет, скорее уж без локалей и фасетов. Потому что у меня горит. Хочется взять и... разломать монитор. Такие дела. Спасибо за внимание :).

Стандартной утилитой для управления настройками дисплея в lubuntu является маленькая утилитка lxrandr. И имеет эта утилита одну неприятную особенность - если нажать там кнопку "сохранить" - в autostart для lxde будет добавлен .desktop-файл с примерно такой командой:

Exec=xrandr --output VGA1 --off

Последствия печальные - сразу после логина в систему xrandr послушно отключает экран. Зачем, как и почему это сделано авторами lxrandr - науке неизвестно. Лечится просто - надо удалить файл /home/USERNAME/.config/autostart/lxrandr-autostart.desktop , где USERNAME, понятное дело, имя пострадавшего юзверя.

Вот, такие дела.

Хочется ещё рассказать про интерференции между QT5, VirtualBox и видеодрайвером гостевых дополнения VBox-а, кои и привели меня к печальному знакомству с lxrandr, но наверное будет это как-нибудь в следующий раз, ибо 2:45 утра понедельника :(.

Linux-версия Code::Blocks, оказывается, не хочет компиллировать проекты если в путях где-нибудь есть кириллица (или любые иные не-ASCII-символы. Лечится внезапно так: залезть в Settings->Environment...->View и включить там чекбокс Internationalization, не выбирая при этом никакой язык. После чего перезапустить IDE.

Что характерно, баг лежит в трекере ещё с 2014 года. До эпического XKB Bug#865, правда, не дотягивает, но возможно всё ещё впереди :).

Нарвался сегодня на очередную весьма типичную ситуацию при пользовании линуксом: накатил lubuntu на виртуальную машину в VirtualBox, вроде бы всё ок, всё работает. Накатил обновления и через менеджер драйверов - пакеты с гостевыми дополнениями виртуальной машины. И началась веселуха - операционка запускается, рабочий стол функционирует вроде бы нормально, но при этом практически никакие графические приложения не стартуют.

Не стартуют вообще. От слова совсем. Запускаем в консоли какой-нибудь synaptic или firefox и видим ровно ничего. В логах пусто, в stderr ничего не выводится, что вообще происходит и пришло ли время переустанавливать шиндоуз систему с нуля в лучших традициях вендузятников 90-х годов - остаётся только гадать.

Но, как оказалось, лечится очень просто. Надо вырубить виртуальную машину, залезть в её настройки и включить там 3D-ускорение (отключенное по умолчанию при создании linux-виртуалки). Спасибо strace за то, что он есть - если бы не тот простой и обнаруженный с помощью strace-а факт, что все приложения падают после чтения библиотеки с именем, прозрачно намекающим на своё отношение к VirtualBox и OpenGL одновременно - танцы с бубном могли бы крайне затянуться :).

Если в Ubuntu установить Lazarus из репозиториев - по умолчанию не будут зарегистрированы mime-типы и не будет нормально работать ассоциация типов файлов с вызовом среды разработки в том же Dolphin-е. Основная проблема в том, что *.lpi-файлы проектов распознаются как обычный xml и если просто добавить ассоциацию с Lazarus - она запомнится на любые xml-файлы. Решение довольно простое - в исходниках lazarus уже есть готовый shared-mime-файл, странно почему мейнтейнеры не добавили его в пакет. Скачиваем http://svn.freepascal.org/svn/lazarus/trunk/install/lazarus-mime.xml куда-нибудь, после чего от имени рута копируем его в /usr/share/mime/packages , после чего запускаем:

sudo update-mime-database /usr/share/mime

Ждём, при необходимости перезаходим в среду рабочего стола или перезагружаемся, но у меня кеды подхватили изменения сразу, без релогина. В принципе, после этого все ассоциации окажутся настроены уже сами по себе.

Всем привет. Давно не писал, но, что называется, накипело. Кому крик души об общих для всех OpenSource-проектов проблемах не интересен - лучше дальше не читайте :).

Однако, дошли руки до того, чтобы восстановить сайт, поломанный злыми китайцами. Граждане, обновляйте жумлу регулярно, или хотя-бы делайте бекапы, иначе как я будете Meld-ом сравнивать пофайлово чистый дистрибутив движка и свой сайт, нафаршированный закладками где только можно и нельзя. Единственный плюс этого всего - опыт не пропьёшь, а посмотреть как выглядят разнообразные php-шеллы и как их прячут было забавно :).

З.Ы. Meld - как оказалось, крайне удобная штука чтобы отследить изменения в каких-нибудь исходных текстах, которые не лежат в этих ваших гитах и субверсионах, ну и просто показывает любые изменения в файлах (включая бинарные) или директориях.

Начиная с 34 версии в Firefox поменяли интерфейс поиска на крайне неудобный вариант с поиском в поисковике, выбранном по умолчанию при нажатии Enter и с необходимостью либо при каждом поиске выбирать отличный от настроенного по умолчанию поисковик мышкой, либо лезть в настройки и, продираясь через кучу диалогов менять настройку по умолчанию. Однако, оставалась возможность сделать финт ушами и переключить в about:config параметр browser.search.showOneOffButtons в значение false - старый интерфейс поиска возвращался обратно.

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

В некоторой степени положение спасает добавленная в одном из релизов возможность переключать поисковик по умолчанию с помощью клавиш Ctrl+Up\Ctrl+Down (т.е. стрелками), без необходимости лезть в настройки, но при большом количестве поисковиков это всё равно менее удобно, чем переключать поисковик двумя щелчками мыши.

Ещё один вариант вернуть старый поиск - воспользоваться расширением Classic Theme Restorer. К сожалению, расширения имеют свойство становиться заброшенными и умирать при смене API, ну и решения в стиле "давайте отрубим им лишние ноги и дадим коляску, а если кто-то хочет ходить пешком - пусть юзает костыли" тоже как-то не алё :(.

горелый винт
В последней (восьмой на момент написания статьи) версии Debian восстановление развалившегося загрузочного software-raid-массива, как оказалось - дело не совсем тривиальное. Когда-то давно, во времена первого GRUB-а - компьютер спокойно загружался при отсутствии части дисков в массиве, однако в 7 и 8 версиях Debian - что-то сломали.

Читать дальше >>>