Ребрендинг KDE

Ээээ... Вообще-то, отладчиком проверьте — на втором ли шаге оно уляжется, чего-то по-моему, я малость промазал... В шагах. :D

>Гткшный софт вроде бы использует не ~/.XCompose, а вшитую таблицу

Ещё недавно всё работало. В т.ч. в Фоксе.

>А кто сейчас-то по каким соображениям запрещает? :)

Никто, просто сейчас не все это поддерживают, увы.

Только вот переменная окружения XDG_CONFIG_HOME не нужна. Ибо, как я выше и пытался доказать, её просто и откровенно может и не быть.

LANG тоже может не быть. Из этого тоже следует, что оно не нужно? :)

пока это не станет «единым стандартом».

Чем спеки fd.o не стандарт?

>Только вот переменная окружения XDG_CONFIG_HOME не нужна. Ибо, как я выше и пытался доказать, её просто и откровенно может и не быть.

facepalm.svgz Ещё раз сказать, что в случае её отсутствия она должна применяться как ~/.config?

>Например, в Kmail от КДЕ3 адресная книга ldap у меня работала без проблем, а в КДЕ4 - вообще не работает

Так вы знаете ответ: создавайте багрепорты.

До сих пор нет темы с таскбаром а-ля виндовс95

Ну, если нет — значит почти никому не нужно. Я, кстати, вместо таскбара использую вывод всех окон на экран в уменьшенном виде, при наведении курсора в левый верхний угол, а вас вот даже закругленные кнопки бесят... Может это старость? ;-)

команда КДЕ занята ребрендингами

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

Так я и не понял, нафига оно надо? Решили по хигу сделать, мол, ползователям сложно запомнить расшифровку?

> Чем спеки fd.o не стандарт?

Для оконных сред стандарт. Для файловых систем? Является ли fdo стандартом... Ну, не уверен... :)))

LANG тоже может не быть. Из этого тоже следует, что оно не нужно? :)

А на сервере есть GNOME или KDE? Или, если на сервере их нет, то оно не нужно? Впрочем, я подкалываю... :)))

На самом деле, если система работает устойчиво, то это не нужно. Если, как в примерах выше, мне необходимо дописывать код, увеличивая число проверок (если getenv(«XDG_CONFIG_HOME) == NULL, то используйте getenv(„HOME“)), то ну его такое решение куда подале... Особенно, если профит весьма относителен. Тупить про соответствие fdo в серверном окружении лучше не нужно... ;)

Я бы понял ваше стремление к „современным решениям“, если бы последовало предложение написать разделяемую библиотеку, которая могла бы не только хранить данные в соответствии с новейшим писком, но и например, позволяла бы шифровать файлы пользовательских настроек, предлагала бы функции парсинга настроек... Ну и так... Чего-нибудь по мелочи... а так... как-то лажовенько получается.

> Ещё раз сказать, что в случае её отсутствия она должна применяться как ~/.config?

Это написано здесь -> http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html, если я не ошибаюсь? Вот это:

If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

Так? И где сказано что это есть «стандарт» для чего-то, окромя fdo? Где на этот документ ссылаются в fhs? Покажите, сделайте милость, документ и конкретную цитату в документе.

Я ещё раз спрашиваю ДЛЯ ЧЕГО, ДЛЯ КАКИХ ЧАСТЕЙ СИСТЕМЫ ЭТОТ СТАНДАРТ ПРИМЕНИМ? Для оконного интерфейса? Ну, и фигли Вы мне тычете его в нос в отношении «файловой системы»? Вашего варианта просто может не быть на сервере. Его и нет. И фигли на сервере забыл стандарт на fdo, я вот то же ни как не пойму...

Вы просто не там роете... Если бы Вы именно unix way интересовались, а не своим положением в оном, то всем было бы проще — Вы бы просто писали действительно нужный код, не отвлекаясь на те «реализации», которые Вам померещились правильными.

>Так вы знаете ответ: создавайте багрепорты.

Кстати, да, люди ждут пока оно заработает, не прилагая усилий. Ребят, все багфиксы в КДЕ - следствие багрепортов. Они не будут пробовать десятьтыщвариантов чтоб все ошибки найти - это фри софтваре, вот и стараемся.

К слову говоря, ВСЕ багрепорты которые я отправлял были исправлены. Срок исправления - не более 3х месяцев.

> просто вместо ~/.foo/, ~/.bar/ будет ~/.config/foo/, ~/.config/bar/.

Никак не пойму - а зачем? Чем это лучше, чем хранить тоже самое в $HOME. Чем это хуже - я вижу. Навскидку:
* это длиннее, будет занимать больше памяти
* это больше кода, т.к. требует дополнительных проверок переменных окружения (кода больше - запускаться будет дольше)
* это дополнительынй вложенный каталог, то есть пара лишних кликов мышью или лишних нажатий клавиш

К тому же - что будет храниться в каталоге ~/.config/ - только конфиги? А если программа создает thumbnail-ы - они должны храниться там же, или в каталоге ~/.thumbnails? А если программа (IM-клиент, например) ведет логи, где их хранить - тоже в ~/.config, или в каком-нибудь ~/.logs? А если у программы есть кеш (mozilla), его хранить в каталоге ~/.cache, или тоже в ~/.config? И т.д.

Так что к предыдущим минусам можно добавить еще один: в каталоге с именем ~/.config по такому «стандарту» будут храниться далеко не конфиги.

Итого, вот минусу, а где плюсы?

PS: Для начала разберитесь сами со своими «стандартами», а потом предлагайте их остальным. :)

>Так? И где сказано что это есть «стандарт» для чего-то, окромя fdo?

facepalm.jpg Научитесь либо читать, либо понимать. Пока что вы не хотите ни того, ни другого.

> Аббревиатура KDE больше не будет означать «K Desktop Environment», а будет использоваться как синоним «KDE community»

Kommunity Desktop Environment? А что, тоже не плохо.

> Научитесь либо читать, либо понимать. Пока что вы не хотите ни того, ни другого.

Я не хочу делать бесполезную работу по совершенствованию «ровного места». Я уже описал в чём был бы профит, если бы была написана system-wide library, которая давала бы:

1. Единый стандарт на чтение/запись конфигов. Подключил к программе, использовал функции типа как в винде, читай-пиши-изменяй-удаляй, причём, единообразно для любой программы, где использована эта либа, меняются только имена параметров и значения параметров. Это было бы просто и удобно и отпалабы нужда ваять собственный код каждый раз, когда нужно поработать с конфигом, т.е., плодить лишний код, когда есть единое решение, пригодное для _всей_системы_.

2. Шифрацию конфигов, с предоставлением возможности пользователю изменить ключ или алгоритм шифрования конкретного конфига. Про использование модулей TPM, aka Fritz-chip'ов я вообще помалкиваю, это недостежимый «пилотаж» в наших условиях «конгениальности». Если бы заюзать TPM, то там можно было бы хранить ключи шифрования для разных программ. И это соответствовало бы макимальной защищённости пользователя. Правда, TPM не столь стоек, как оно требуется для «гарантированной стойкости», но это уже другой вопрос. Для нужд «коммерсов» оно вполне-вполне. В ядре поддерживается. Библиотеки поддержки так же есть. ;) Могу ткнуть пальцем где искать.

3. И вот уже в качестве крема поверх пирожка я бы добавлял сюда возможность работать как с HOME, так и с XDG_CONFIG_HOME... Для полного счастья. Ибо при решённых пп 1 и 2, оно будет хотя бы интересно. А не похоже на пылесошенье бескрайних просторов Сибири.

А так... А так пока получается что переменная HOME, определяемая в /etc/profile, т.е. для system-wide случая к использованию более пригодна, нежели XDG_CONFIG_HOME, которая определяется для пользовательских процессов. Надеюсь, ни кто не рискнёт спорить с тем, что X-server в общем и целом как и любая из оконных оболочек есть пользовательские процессы, а не системные. В противном случае (если кто всё-таки рискнёт спорить), я сделаю вывод о том, что KDE это такая «опреационная система». И меня это весьма сильно посмешит. :)

Если, как в примерах выше, мне необходимо дописывать код, увеличивая число проверок

Да, пару лишних строк придётся написать.

Я бы понял ваше стремление к «современным решениям», если бы последовало предложение написать разделяемую библиотеку, которая могла бы не только хранить данные в соответствии с новейшим писком, но и например, позволяла бы шифровать файлы пользовательских настроек, предлагала бы функции парсинга настроек...

Почитай basedir-spec (выше уже давали ссылку), autostart-spec и им подобные. XDG - это не только ценный мех каталоги для конфигов.. :)

>Никак не пойму - а зачем?

Пример с бэкапами уже приводили. Да и просто, если в файловом менеджере по каким-то причинам показ скрытых файлов д.б. включён., работать в хомяке очень неудобно.

К тому же - что будет храниться в каталоге ~/.config/ - только конфиги? А если программа создает thumbnail-ы - они должны храниться там же, или в каталоге ~/.thumbnails? А если программа (IM-клиент, например) ведет логи, где их хранить - тоже в ~/.config, или в каком-нибудь ~/.logs? А если у программы есть кеш (mozilla), его хранить в каталоге ~/.cache, или тоже в ~/.config? И т.д.

Ты же сам (или твой анонимный коллега) давал ссылку на basedir-spec. К чему тогда эти вопросы?

Для начала разберитесь сами со своими «стандартами», а потом предлагайте их остальным. :)

Все уже давно разобрались, один анонимус воду мутит. :)

>Я уже описал в чём был бы профит, если бы была написана system-wide library

Несколько строк накатать так сложно, да. :)

Шифрацию конфигов, с предоставлением возможности пользователю изменить ключ или алгоритм шифрования конкретного конфига.

Причём здесь шифрация, не совсем понятно (точнее совсем непонятно).

Кстати, выделение конфигов отдельный каталог даёт возможность примонтировать этот каталог в зашифрованный раздел. А с XDG_CACHE_HOME можно, к примеру, один кэш сделать общим для всех юзеров и для всех машин (если какая-то прога генерит кэш особенно долго и особо крупных размерах). Вот тебе и профиты. :)

А так пока получается что переменная HOME, определяемая в /etc/profile

ЩИТО???

> ЩИТО???

Виноват. Исправлюсь. Я имел ввиду, что переменная HOME определяется для любого пользователя в системе. Я НЕ правильно написал что она определяется в /etc/profile, она определяется в файле, содержащим данные об учётных записях пользователей. Как правило, /etc/passwd. Правда, полагаться на этот файл в своём коде я бы не стал, т.к. рекомендована к использованию функция getpwent(), описанная в <pwd.h>...

Ну, виноват... Виноват... :) Посыпаю пеплом голову... :)))

Причём здесь шифрация, не совсем понятно (точнее совсем непонятно).

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

Т.е., например, есть пользователь, у него есть ноут. На ноуте установлена Linux-версия софта, который (например) логинится в БД. Учётка для БД хранится в зашифрованном конфиге вместе с настройками данной программы (адрес, порт, имя пользователя, пароль, дата последнего обращения к БД, ключ SSL, что угодно или что Вам ещё может прийти в голову). Доступ к этой информании заблокирован паролем, который назначается пользователем и хранится, например, в модуле TPM. Пример из этой области, но отвязанный от «конфигов» -> https://www.grounation.org/index.php?post/2008/07/04/8-how-to-use-a-tpm-with-... Как оно вообще работает.

Таким образом, даже в случае, если пользователь потеряет свой ноут, за разумное время ни кто не сможет воспользоваться этой учёткой к БД а пользователь может например, получить новый ключ SSL (да, получить, т.к. по выделяем пользователю ключу аутентифицировать «интереснее», чем по паролю или его хэшу в МД5).

Если пользователь не теряет свой ноут, а просто работает, то он может не волноваться насчёт аутентификации и авторизации. Ему достаточно _один_ раз аутентифицироваться в _своей_ системе, чтобы его программы самостоятельно, основываясь на данных из конфигов (кстати, расшифровываемых «налету») могли бы предоставлять ему доступ к информации прозрачным для него (пользователя) образом.

> Кстати, выделение конфигов отдельный каталог даёт возможность примонтировать этот каталог в зашифрованный раздел.

Можно. Но ненужно. Во-первых, не стоит складывать в одну кучу конфиги и пароли. Во-вторых, один пень надо мудровать с cryptoloop. В третьих, и сейчас ровным счётом ни что не мешает так делать.

А с XDG_CACHE_HOME можно, к примеру, один кэш сделать общим для всех юзеров и для всех машин (если какая-то прога генерит кэш особенно долго и особо крупных размерах). Вот тебе и профиты. :)

А вот так делать совсем-совсем не нужно. Уж поверьте... ;) У Брюса Шнаера найдите ответ АНБ на вопрос насколько криптостоек алгоритм АЕС... Мне Вы наслово не поверите, боюсь... :)))

> Да и просто, если в файловом менеджере по каким-то причинам показ скрытых файлов д.б. включён., работать в хомяке очень неудобно.

Выключите, разрешаю... :))))

> Почитай basedir-spec (выше уже давали ссылку),

Ты не поверишь — ссылка и цитата оттель мною и давались. Читал я уже... Читал... Отсюда и такое отношение. Бред это. Версии 0.6. Не более.

Я тут вам не зря про TPM-то пишу. Если уж вы бросаетесь чего-то усовершенствовать до посинения, то хотя бы усовершенствуйте что-то реальное, а не студенческие придумки. ;)

Лучше бы убрали дебильные вставки буквы K, где это противоречит орфографии.

>Я НЕ правильно написал что она определяется в /etc/profile, она определяется в файле, содержащим данные об учётных записях пользователей.

Кстати, переменные XDG_* действительно опеределяются в /etc/profile.d/xorg.sh. :) По крайней мере, в арче.

Учётка для БД хранится в зашифрованном конфиге вместе с настройками данной программы (адрес, порт, имя пользователя, пароль, дата последнего обращения к БД, ключ SSL, что угодно или что Вам ещё может прийти в голову).

Что-то подобное видел в gconf, но толком не разбирался. В любом случае там такое можно организовать через бэкенды.

>Выключите, разрешаю...

Спасибо, но я лучше буду ратовать за наведение порядка в хомяке. ;)

>Читал я уже... Читал... Отсюда и такое отношение. Бред это. Версии 0.6. Не более.

Не бред, а способ отделить зёрна от плевел и предотвратить разведение помойки a-la C:\WINDOWS\.

> Что-то подобное видел в gconf, но толком не разбирался. В любом случае там такое можно организовать через бэкенды.

В данный момент — «да». Через бекэнды и только. Я же ратую (например) за то, чтобы с уровня бэкенда этот подход вышел бы на уровень «стандартной либы» (system-wide library).

Поясню откуда ветер дует. У меня служебная машинка — таблетка от Gateway. C-142XL. На ней есть и TPM и сканнер отпечатков пальцев. Я давным-давно уже не ввожу пароли «врукопашную». Только «пальчики»... :) Но незадача — сейчас «ввёл пароль», через cryptoloop монтируется «нужная» партиция и мы начинаем работать.

Кстати, изначально я извратился по поводу StegSF, стеганографическая ФС, которая ставится «поверх ext2» и хранит данные с большой избыточностью в «свободных блоках» HDD. Даже если мой винт попадёт в «кроватку» для посекторного чтения (а такие есть, можете мне поверить наслово), то там будет «мусор» как в случае, если там что-то было записано, а потом стёрто. Данные там ещё и шифруются. Проект довольно древний, но он работает. Сейчас пришлось с него отползать со слезами на глазах. Ну не кошерен ext2 уже... А с рейзером оно хреново дружит. Ссылка на то, откуда начинать копать -> http://forum.sources.ru/index.php?showtopic=44130 Я это лет пять назад ещё писал... :)))

Так вот. В случае, если либа, работающая с конфигами, в состоянии работать с TPM, получается что нам нет нужды в бэкендах (я _НЕ_ЗРЯ_ говорю про system-wide library). Нам нет нужды криптовать что-либо софтом. Сам по себе TPM основан на ATMega8, так что там шифратор есть полу-аппаратный. А он даёт изрядный прирост в скорости только за счёт того, что ключи хранятся в той же микрухе, алгоритм работает в той же микрухе... По сути дела блок данных извне пришёл, обработался, ушёл. Всё. Скорость довольно хорошая.

На уровне прикладного ПО это может выглядеть типа пакета Seahorse, но с «брелком» в железке. Через ту же либу программьё обращается к TPM, получает оттуда данные и дальше с ними работает. Изменить данные в памяти довольно сложно. Изменённые данные будут жить ровным счётом пока не будут считаны заново из TPM. Изменить данные в TPM? Ну, это так же гиморно. Нужно для этого все права иметь... Так что... почти безнадёга. И необходимость тратить ресурсы на cryptoloop отпадает. Совершенно. Экономия ресурсов налицо.

Короче, про TPM, если кому интересно. Даташиты - http://category.alldatasheet.com/index.jsp?semiconductor=TPM Они, от разных производителей, почти одинаково устроены... :) Базовые спецификации и т.д. и т.п. -> http://www.trustedcomputinggroup.org

Как с ними работать в Linux — http://sourceforge.net/projects/trousers/ релиз от IBM. http://trousers.sourceforge.net/tpm_keyring2/quickstart.html и http://trousers.sourceforge.net/tpm_keyring2/ecryptfs.html Последние две ссылки — немного не то, что я хочу. К сожалению.

Как-то так, в общем...

> Спасибо, но я лучше буду ратовать за наведение порядка в хомяке. ;)

Ну, блин... Экий Вы, батенька... Привереда, право... :))) Всё же проще... Я специально для Вас заемерджил себе mc (обычно им не пользуюсь, но тут-то думаю, как не помочь людям — мучаются же). Там всё оказалось очень просто — открываем mc, прессуем F9, выбираем «Настройки», первый пункт меню — «Конфигурация», в «Параметрах конфигурации», в левой верхней панельке («Настройки панелей»), снимаем «галочку» («крестик») в пункте «Показывать скрытые файлы» и сохраняем конфиг.

Всё. Опосля приведённых действий, Вам полегчает. И не надо никому мозг ееее...^W эээ... «ни за что ратовать», я хотел сказать... :)))))))

> Не бред, а способ отделить зёрна от плевел и предотвратить разведение помойки a-la C:\WINDOWS\.

Думаете? :) 40 лет не хватило чтобы понять что надо а что нет? Ну, как скажете... :)

>оба движутся в направлении венды

Гном --> Макось
КДЕ --> виндусь

>открываем mc, прессуем F9, выбираем «Настройки», первый пункт меню — «Конфигурация», в «Параметрах конфигурации», в левой верхней панельке («Настройки панелей»), снимаем «галочку» («крестик») в пункте «Показывать скрытые файлы» и сохраняем конфиг.

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

>40 лет не хватило чтобы понять что надо а что нет?

Не знаю, как было 40 лет назад, но сейчас те же кеши браузеров и смотрелок могут тянуть на несколько сотен метров, и тянуть их в свои бекапы у меня нет никакого желания. Точно также, как нет никакого желания составлять для tar файл исключений со 139ю строками (кстати, вся эта куча неплохо растягивает время архивации) и обновлять его каждый раз, когда какое-то приложение было удалено/поставлено.

> Знаю, только вот проделывать эту операцию каждый раз, когда я захожу в хомяк, очень неудобно.

Прошу прощения, а сохранять конфиг mc не пробовали? :) Я раз сохранил, сейчас вот поглядел — оно сработало. Сейчас, правда, mc снесу, ибо без него мне проще... Чуть было не забыл...

> Не знаю, как было 40 лет назад, но сейчас те же кеши браузеров и смотрелок могут тянуть на несколько сотен метров, и тянуть их в свои бекапы у меня нет никакого желания. Точно также, как нет никакого желания составлять для tar файл исключений со 139ю строками (кстати, вся эта куча неплохо растягивает время архивации) и обновлять его каждый раз, когда какое-то приложение было удалено/поставлено.

Можно упростить скрипт. Банально не архивируя каталоги, которые явно не нужны. Например, все, начинающиеся с ".". Кстати, я так бекапы и делаю. Впрочем, в последнее время, я архивировал рабочий каталог где-то с полгодика назад. Всё остальное (важное) в git'е. Или в каталогах, которые можно без напряга затарить. Единственное, что выпадает из списка — бекапы закладок от мозиллы. Но тут уже я их просто экспортирую. И evolution'овские данные. Правда, все данные окромя писем хранятся на сервере конторы (и адресная книга и «календарь»), а письма я не храню вообще. По прочтении либо сразу в топку, либо сохраняю в подкаталоге рабочего каталога. Так проще. И вложения (если есть и они нужны зачем-то), то так же сохраняю.

>Гном --> Макось

КДЕ --> виндусь

Siado --> ?

>>Знаю, только вот проделывать эту операцию каждый раз, когда я захожу в хомяк, очень неудобно.

Прошу прощения, а сохранять конфиг mc не пробовали? :)

Спасибо, Кэп. :) Но я mc в основном использую для хождения по системным и скрытым каталогам (для остального есть дольфин), т.ч. показ скрытых файлов нужен. Но когда надо, к примеру, перекинуть пару файлов между юзерскими хомяками, эти файлы начинают жутко мешать. Даже просто каша из скрытых и нескрытых каталогов/файлов раздражает (возможно, сортировку можно поменять, только у меня нет на это никакого желания).

>Например, все, начинающиеся с ".".

А если у юзера есть собственные скрытые каталоги? К слову, у tar файлы, указанные в exclude, имеют приоритет на файлами из include. Конечно, можно извратиться с генерациями списка файлов или tar --append, но по-моему проще втолковать разрабам, что документы, конфиги, кеш и локальные данные суть разные вещи и должны храниться в разных местах.

> В данный момент — «да». Через бекэнды и только. Я же ратую (например) за то, чтобы с уровня бэкенда этот подход вышел бы на уровень «стандартной либы» (system-wide library).

Единая библиотека для считывания и разбора конфигов? Зачем? Такую единую библиотеку уже пытались создать, ничего хорошего не вышло - так получился реестр винды.

Почему-то некоторые забывают, что кроме конфигов программы хранят много всего (кеш, логи, временные файлы, сертификаты, шаблоны, скины, плагины...) И разработать универсальную библиотеку, которая покроет все это... Такая библиотека уже есть - это функции read/write файловой системы. Для отдельных видов данных тоже давно есть библиотеки (libpng для картинок, libxml для древовидных текстовых данных и т.д.) Какая из задач не покрывается существующими библиотеками?

К тому же файловая система вполне позволяет добавить шифрование для любого нужного каталога или группы каталогов. И для программ это будет намного удобнее и прозрачнее, чем «system-wide library». Вот и получается, что лишний уровень абстракции над файловой системой будет... лишним.

На ней есть и TPM и сканнер отпечатков пальцев. Я давным-давно уже не ввожу пароли «врукопашную». Только «пальчики»... :) Но незадача — сейчас «ввёл пароль», через cryptoloop монтируется «нужная» партиция и мы начинаем работать.

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

Или в чем, собственно, была идея? Для чего еще использовать TPM? Для тивоизации, что-ли?

> Гном --> Макось

КДЕ --> виндусь

виндусь --> Макось
Макось --> линукс

так и ходят по кругу...

В упор не вижу смысла в данном ребрендинге. Ну и иже с ними. Три дня работы в гноме == отказ от Квредной привычки. Два дня работы в fluxbox и ты понимаешь, что жизнь прекрасна. :)

> изначально я извратился по поводу StegSF ... Сейчас пришлось с него отползать со слезами на глазах.

А MagikFS или Scramdisk не работают?

Еще есть hidden volume в truecrypt.

Ппц логика: сам живет знаниями и привычками прошлого века, при этом не делает попыток саморазвиться и обвиняет разработчиков софта в том, что они софт развивают.

По-твоему «саморазвиваться» - это хавать прозрачные говноперделки? Нуну

> Единая библиотека для считывания и разбора конфигов? Зачем? Такую единую библиотеку уже пытались создать, ничего хорошего не вышло - так получился реестр винды.

Ну, идея, положим, относительно хорошая. Особенно, если использовать не программные, а аппаратные средства обеспечения безопасности. А так... да... «реестр вянды»... И в этом плане что HOME, что XDG_CONFIG_HOME — что е?ать подтаскивать, что ё?аных оттаскивать... Без разницы.

Почему-то некоторые забывают, что кроме конфигов программы хранят много всего (кеш, логи, временные файлы, сертификаты, шаблоны, скины, плагины...) И разработать универсальную библиотеку, которая покроет все это... Такая библиотека уже есть - это функции read/write файловой системы. Для отдельных видов данных тоже давно есть библиотеки (libpng для картинок, libxml для древовидных текстовых данных и т.д.) Какая из задач не покрывается существующими библиотеками?

Изо всего перечисленного интересуют только «сертификаты» и данные для парольной аутентификации. Иногда сертификат получить гиморнее, чем его надлежащим образом сохранить. Касаемо всего остального — это не критичные данные. Их можно сносить-восстанавливать как и сколько угодно. В самом крайнем случае — затарить в тупую и не париться, чай не на дискеты бекапы сохраняем...

Касаемо функций доступа к данным, здесь важнее не «как», а «что» и «откуда» читать. Да. POSIX и функции ввода-вывода законодательно не отменяли. Однако, остаётся вопрос — мы читаем/пишем просто конфиг или мы читаем/пишем информацию, чувствительную к доступу? Значащую, иными словами...

К тому же файловая система вполне позволяет добавить шифрование для любого нужного каталога или группы каталогов. И для программ это будет намного удобнее и прозрачнее, чем «system-wide library». Вот и получается, что лишний уровень абстракции над файловой системой будет... лишним.

Файловая система в случае применения TPM здесь примерно как зайцу триппер. Всё просто. Она не используется для хранения значащей информации. С другой стороны, если мы переходим к использованию «железки», то огород городить из 10-20-30 дополнительных программ для доступа смысла нет. Гораздо проще использовать одну библиотеку.

Чуть не забыл...

Это - что, предложение заменить ввод паролей от шифрованных разделов отпечатками пальцев? Защита критические данные отпечатком не выглядит надежной.

А для «собаки» или «двух собак» и не предлагается. Для коммерсов — вполне-вполне. Они потенциально не в состоянии запомнить сложный пароль. К сожалению. Уж пусть лучше так, чем пароль типа «123», который крайне чувствительнен к угадыванию. Я бы с удовольствием кинул ссылку на книгу про «password guessing», только один хрен читать не будете (ссылки про TPM, судя по последнему предложению Вашего постинга, не осилили, а здесь посложнее малость). Расскажу вкратце своими словами — там чувак собрал порядка 4 млн. «плохих паролей». И с удивлением обнаружил, что все 4 «ляма» просто уложились в пятьсот паттернов. Уже легче, не так ли? :)

Тогда что эффективнее — заставлять юзера вводить пароль ХЗ какого вида, который он один пень не запомнит, а запишет где-то (как следствие — потеряет, разгласит или что ещё придумает), или заставить провети пальчиком по сканнеру? И в случае его аутентификации на внешних ресурсах кто даст гарантию что в «одноклассниках» он не использует того же пароля, что и для доступа к корпоративной VPN (он же _помнит_ пароль к VPN чётко)? Или, может, пусть железочка поможет ему в генерации пароля и его хранении? Чисто для «однотрахников» или «мыло.ру»? ;) А пароль для VPN пусть будет паролем к VPN.

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

Бррр... Большая просьба — не надо больше смотреть/читать детективов. Это фигня. Полная. Спросите у любого судмедэксперта — какие отпечатки и какого качества он откатает со слегка шероховатой поверхности ноута? В случае с тонкой полоской сканера, Вам придётся не просто «подержать пальчик» на сканере, а провести по нему. Замечу из опыта. В результате в транспорте, дай Бог, раза с третьего будете давать хороший отпечаток. И то после «тренировки». Положение пальчика немного «не то», наклон «не тот», рука вспотела, дрогнула при вводе, всё — тренируемся ещё раз.

Или в чем, собственно, была идея? Для чего еще использовать TPM? Для тивоизации, что-ли?

Батенька, я не могу себе представить как (если подозревать что по ссылкам о TPM Вы прогулялись) в Вашу голову постучался такой «вывод». Вообще, откуда это? Для тивоизации довольно и более простых средств. Зачем для неё крипто-engine? Зачем хранить ключи? Нет. Я решительно отказываюсь это дальше обсуждать. По причине того, что при таком «выводе» обсуждать тут, мягко говоря, нехуя.

> А MagikFS или Scramdisk не работают?

Сожалею, но MagikFS это дальнейшее развитие -> http://www.cl.cam.ac.uk/~mgk25/ih99-stegfs.pdf всё той же StegFS. С точно такой же ориентацией на ext2fs в качестве «базовой». Т.е., по сути дела, те же яйца, вид в профиль.

Scramdisk — это вообще не в ту кадушку. Уж простите. Мне нужна максимальная _скрытность_, причём, осуществляемая без разного рода извратов на почве переразбиения дисков.

Еще есть hidden volume в truecrypt.

И это вослед за Scramdisk. Мне _НЕ_ нужны варианты, основанные на переразбиении диска, на создании доп. партиций. Они всегда «заметны» если читать диск.

В случае со стегфс, партиция создавалась, но через дополнительный софт, который можно было просто поставить/переименовать чтоб не палиться, или переустановить при необходимости. Никаких дополнительных партиций ни где не создавалось. Доступ к данным на таком «диске» — только через программьё на пользовательском уровне.