Журнал Витуса. Голосов: 2 Адрес блога: http://vitus-wagner.livejournal.com/ Добавлен: 2008-02-19 12:48:41 блограйдером Lurk

Про xdg-open и xdg-mime

2017-07-01 21:52:33 (читать в оригинале)

После апгрейда debian-а почему-то вдруг всякие разные програмы вплоть до fossil стали при попытке открыть из них URL запускать ублюдство от гугля (плевать что в данном случае опенсурсное - все равно ублюдское и с проксями работать не умеет по-человечески), вместо нормального файрфокса. Хотя у меня вроде альтернатива x-www-browser была выставлена правильно.

Расследование показало, что большая часть современных программ, когда им надо открыть URL-ку запускают не Debian-specific x-www-browser, а "универсальный" и "стандартный" xdg-open. Который настройку альтернатив игнорирует и пользуется своей базой настроек.

Как выяснилось, искать нужную настройку нужно не в xdg-settings, а в xdg-mime.
Если у этой программы спросить а кто у нас умолчательный обработчик mime-типа
x-scheme-handler/http, то тут-то и выяснится, откуда берется chromium. И в этом месте как раз и можно поменять то что вызывается по xdg-open. Кстати, обработчики для http и https нужно менять отдельно. А то http-урл-ки будут открываться правильно, а https в том, что в голову freedesktop.org взбрело.

Заодно с помощью xdg-mime можно оторвать привычку файлменеджеров открывать постскрипт гимпом, а не evince.

Насколько я понимаю, работа через командно-строчную утилиту xdg-mime - универсальна и десктопно-независима (хотя xdg-open делает попытки выбирать браузер в зависимости от десктопа).

Кроме того xdg-mime имеет полезную функцию query filetype. Она позволяет узнать, какому именно типу mime нужно поменять дефлотный обработчик, если у вас типичным не тем открывается конкретный файл. К сожалению, на url-ку это не срабатывает.

P.S. А вообще в современных линуксах сильно не хватает профайла all users. Поскольку изменения, связанные с эволюцией софта приходится вносить куда чаще, чем заводятся новые пользователи, и вносить именно пользовательскую конфигурацию. Все же локальное "all users" данной машины и /usr/share, находящееся под управлением пакетного менеджера, это сильно разные вещи. Надо покопаться, может быть xdg умеет что-то из /usr/local читать.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1919586.html. Please comment there using OpenID. Now there are comments

---

Еще про stretch

2017-07-01 10:36:44 (читать в оригинале)

Выяснилось, что stretch я похвалить немного поторопился.

Как оказалось он молча, без вопросов апгрейдит keepass 0.43 на keepass 2.0.3.

Засада в том, что keepass <2 и keepass 2.x это программы у которых нет ничего общего, кроме названия и назначения.

Например, несовместим формат файлов. То есть keepass 2.x умеет один раз симпортировать базу от 1.x но записать обратно - уже никак.

А я держу keepass в качестве менеджера паролей ровно потому что он позволяет копировать базу как файл между разными устройствами с разными операционными системами. Поэтому ситуация когда на одном устройстве один формат, на другом другой - меня категорически не устраивает.

Поставил пока пакеты из jessie на hold. И думаю - стоит переходить на keepass 2.x
или не стоит?

Что-то мне все андроидные клиенты, совместимые с keepass2 вызывают подозрение:

У keepass2android интерфейс переписан с java на mono. Это для андроид-то!
KeePassMob содержит в себе код работы с сетью (dropbox), что по-моему для пассворд-менеджера под андроид категорически недопустимо. Поскольку уж если в этой дырявой системе есть способ защититься от доступа в сеть, то именно пассворд-менеджер обязан это сделать.

Поэтому я думаю о том, что может быть стоит еще какой password-manager поискать.

Требования:

1. Наличие клиентов для linux и android
2. Приемлемая usability для android, у которого жутко неудобная работа с clipboard
3. Приемлемая юзабилити под X11.
4. Возможность копирования базы паролей с устройства на устройство как файла по ЛЮБОМУ
протоколу передачи файлов scp, obex, smb.
5. Наличие в базе хотя бы пары дополнительных колонок кроме имя и пароль.
В качестве бонусов:
5. Команд-лайн интерфейс под linux.
6. Возможность хранения базы паролей в version control.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1919482.html. Please comment there using OpenID. Now there are comments

---

stretch на ноутбуке

2017-06-30 17:40:12 (читать в оригинале)

Тут уже несколько дней назад сделал на ноутбуке dist-upgrade на stretch.

Это был самый беспроблемный dist-upgrade со времен пожалуй что, hamm ( а раньше я просто Debian-ом не пользовался).

То есть даже не пришлось перезапускать apt-get dist-upgrade несколько раз. Все с одного раза отконфигурировалось.

Правда, все хитрое и сложное у меня версии не изменило - ядро из бэкпортов, либреофис из бэкпортов и т.д.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1919171.html. Please comment there using OpenID. Now there are comments

---

Жизнь без сетей- 2

2017-06-30 09:33:52 (читать в оригинале)

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

https://qz.com/1017457/there-is-a-point-at-which-it-will-make-economic-sense-to-defect-from-the-electrical-grid/

Примерно про то же я писал в ХиЖ в марте прошлого года

Автор, правда, полагает что еще минимум десятилетие солнечные батареи будут неспособны обеспечить питание домохозяйства по крайней мере несколько дней в году, в периоды экстремально плоходй погоды, и предлагает сохранить подключение к сети в качестве резервного варианта.

По-моему, он не прав. Электрическим сетям крайне невыгодно, если их будут использовать не как основной источник, а как резервный. Платим мы за электричество по счетчику, а большая часть расходов будет при этом идти на содержание сети. Так что они либо будут брать немаленькую плату за подключение, либо вообще требовть чтобы выработанная вашими собственными батареями энергия проходила через их приборы учета, как в Европе.

Поэтому, если солнечные батареи не справляются действительно 3-4 дня в году, надо ставить в качестве бэкапной системы бензогенератор. И топливо для него запасать в бочке в сарае. Потому что как раз в эти три дня, когда не будет на небе Солнца, будет проблема и с тем, чтобы на бензозаправку съездить. Мост там какой-нибудь смоет или поперек дороги дерево упадет.

А вот как раз в то, что автономная система из солнечных батарей, Powerwall и бензогенератора на всякий случай уже сейчас окажется дешевле чем оплата строительства километров этак шести линии электропередачи, я вполне готов поверить.

P.S. Еще интересная тема для размышлений - PowerWall vs полсотни автомобильных аккумуляторов с внешним контроллером заряда. Powerwall при равной емкости заметно дороже. Но это единое необслуживаемое устройство, которое висит на стенке в жилой комнате и моргает красивым светодиодом.
А для кучи автомобильных аккумуляторов потребуется городить отдельное помещение, да с вентиляцией, чтобы водород выходил, аккуратно прямыми руками их подсоединять и периодически заменять.

Правда, там где иначе нужно тянуть 6 километров ЛЭП с отдельными помещениями обычно проблем нет. И с прямыми руками у тех, кто это хозяйство обустраивает- тоже.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1918886.html. Please comment there using OpenID. Now there are comments

---

Шредер

2017-06-30 09:15:11 (читать в оригинале)

Задумался о том, когда было изобретено такое устройство, как шредер.

Как мне кажется, ещё в XIX веке идея уничтожать документы таким способом никому не могла прийти в голову.
В каждом кабинете обязательно присутствовало устройство для работы с открытым огнем - камин, свечи, масляная или керосиновая лампа. Кстати и идея о запрете курения в конторах тогда никому не приходила в голову, так что были и пепельницы под рукой.

В общем, документы было проще сжечь, чем в лапшу резать.

Посмотрел в википедии. И правда - 1909 год.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1918567.html. Please comment there using OpenID. Now there are comments