В традиционной парадигме 70-х годов у данных, которые лежат на диске владельца (не в смысле ...
В традиционной парадигме 70-х годов у данных, которые лежат на диске владельца (не в смысле пользователя в многопользовательской системе, а в смысле какого-то куска программного кода) нет.
Приходи кто хочешь, бери файл, копируй, перемещай, меняй в нем байтики.
И у этого подхода есть масса преимуществ. Во-первых, прекраснореализуется toolbox phylosophy. Во-вторых, авторам приложений не нужно думать о поддержке таких операций как бэкап, или о способах передачи данных по сети - это можно поручить отдельным программам - сетевым FS, ftp-клиентам и т.д, и они прекрасно справятся с любыми данными.
Но чего-то в этой парадигме не хватает, и ее постоянно пытаются поломать. Из тех примеров, с которыми приходилось сталкиваться лично мне, первым была MacOS classic, с атрибутами creator и owner у файла. Концепция была, конечно. сильно кривая и мешала, когда нужно обрабатывать некие данные несколькими программами.
Но тем не менее, почему-то подобные концепции постоянно пытаются пролезть в энд-юзресккие операционные системы. Причем не только в виде необязательных настроек вроде ассоциации расширений с приложениями.
Вот в Андроиде, например, появился механизм Intents, который позволяет опять же работать в парадигме тулбокса, но уже над набором приложений-обработчиков данных, а не файлов. Ему, правда не хватает стандартизованных механизмов для бэкапа и обмена данными с другими устройствами, но это задумка такая - привязать пользователей к чужим облачным сервисам, чтобы нельзя было список покупок с компьютера на телефон скопировать, не пропусти в его через индексатор фирмы, торгующей контекстной рекламой.
Или для обмена данными по шнурку вместо избыточно низкоуровневого для этой цели USB Storage используют не протокол уровня файловой системы (SMB, например), а какой-нибудь PTP или MTP.
Если вдуматься, то вообще-то клиент-серверные базы данных и всякие веб-сервисы это примерно то же самое. Вместо того, чтобы хранить данные в файловом хранилище, к ним приделывают процесс, который реализует свою собственную политику доступа, и реализуют какой-то протокол взаимодействия с этим процессом. Иногда не один - вот у ЖЖ, например. есть один протокол для доступа из браузера, а второй - API для всяких программ-клиентов.
Я регулярно сталкиваюсь с описаниями OpenSource проектов, которые норовят использовать D-Bus в качестве аналога андридных интентов и передавать по ней данные от процесса-владельца данных к процессу-потребителю данных. Получается, естественно, плохо. Но упорство таких попыток о чём-то свидетельтсвует.
Я вот тут задумался над вопросом, а какая нужна надстройка над протоколом, подобным интентам, чтобы реализовать те полезные возможности файловой системы, которых нас лишает андроид, стремящийся максимально изолировать приложения друг от друга.
1. Нужен стандартизированный протокол бэкапа. То есть любое приложение, которое хоть что-то хоть где-то хранит (ну кроме очень специальных случаев вроде HSM, должно поддерживать операцию "скачать всё" и, по возможности - "скачать изменения со времен такого-то бэкапа", а также "восстановить вот это".
В принципе, даже HSM-ы можно бэкапить, если предусмотреть защиту бэкапа секретом, который хранится где-то отдельно от бэкапа.
2. Нужен стандартизованный object sharing протокол. Что-то вроде того же PTP или MTP - посмотреть какие объекты есть в библиотеке у данной программы, вытащить указанный объект в виде, пригодным для того, чтобы скормить аналогичному приложению на другом устройстве, положить объект.
Возможно, в обоих случаях нужно поддерживать что-то типа rsync-протокола, то есть возможность передачи по кускам с контролем целостности.
Ну и нужен качественный набор паттернов разделения менеджера данных и приложения с пользовательским интерфейсом. Хотя все равно хрен соблюдать будут. В мире где наиболее распространенным языком является php, созданный для того, чтобы смешивать логику и представление, идея разделения этих двух сущностей будет оставаться благим пожеланием.
Upd А придумает ли кто-нибудь третий случай операции кроме "забэкапить все" и "поделиться избранным", применимый к ЛЮБОЙ информации хранящейся на устройстве? (понятно что варианты "открыть в соответствующем приложении" и "стереть нафиг" не в счет).
This entry was originally posted at http://vitus-wagner.dreamwidth.org/1120256.html. Please comment there using OpenID. Now there are 
comments
Похоже, что желание создать нормальное Free Software, в смысле, такое, которое пользователь ...
Похоже, что желание создать нормальное Free Software, в смысле, такое, которое пользователь действительно свободен модифицировать, потому что способен понять, таки начинает у народа возникать.
Вот, например, Tomb, юзер-френдли инструмент для создания криптованных дисков, написанный на shell. Под лозунгом complexity hides insecurity.
Надо, что-ли почитать, и понять, удалось авторам добиться заявленных целей, или insecurity пробралась в проект с другой стороны.
Но в общем и целом подход вполне заслуживает внимания.
This entry was originally posted at http://vitus-wagner.dreamwidth.org/1110324.html. Please comment there using OpenID. Now there are 
comments
Вот смотрю я на развитие проекта Devuan и думаю, что форк без systemd это, конечно, благая идея. Но ...
Вот смотрю я на развитие проекта Devuan и думаю, что форк без systemd это, конечно, благая идея. Но если не отказаться от GTK и Qt, создать систему в которой от использования GUI будет легко перейти к его модификации, не получится.
This entry was originally posted at http://vitus-wagner.dreamwidth.org/1038355.html. Please comment there using OpenID. Now there are 
comments
And Spieces Album: ...
Тут в процессе дискуссии вылезла странная мысль.
Что в общем-то плох не init как таковой, ...
Тут в процессе дискуссии вылезла странная мысль.
Что в общем-то плох не init как таковой, а соглашения по написанию скриптов для него.
Ну и не хватает нескольких инструментов для того, чтобы реализовать некоторую полезную функциональность. Например, иниттабовский respawn в соврешменных условиях почти бессмысленен.
В связи с этим возникла мысль, придумать в качестве замены нынешнему sysvinit
1. Протокол взаимодействия init-скриптов с окрущением (в которое кроме собственно запускалки всех скриптов требуемых по данному событию входит еще и утилита update-rc.d как минимум). Именно протокол. Сам скрипт может быть чем угодно, начиная от makefile, и кончая вообще бинарником. Внутрь вообще никто глядеть не должен, никакхи manchine-readable comments. Поэтому рассказывать о том, от чего скрипт зависит он должен при ВЫЗОВе с параметром depends, а про то, на каких ранлевелах он предполагает запускать и стартовать свой сервис - при вызове с параметром runlevels
Протокол, естественно, делается таким, чтобы существующие шелловские init-скрипты требовали минимальной доработки. В идеале - только замены lsb-style комментариев на то, что будет реализовывать соответсвующую часть протокола.
2. Специальный инструмент для запуска демонов, скриптами для которого должны быть 80% инит-скриптов. В качестве основы для такой запускалки берется start-stop-daemon. Слегка дорабатывается, чтобы мог работать как интерпретатор скриптов, состоящих из тех же команд, которые он сейчас из командной строки понимает. Получается такая чисто декларативная описаловка.
Туда же можно прикрутить функциональность watchdog в качестве одного из сценариев работы.
3. Во всех прочих случаях по возможности использовать не специальные, а какие-нибудь general purpose инструменты. Например, make(1) вместо startpar(8).
4. Видимо, все же на уровне самого init-а - обеспечить чтобы выдача шла не на консоль, или не только на консоль. Как меня это всю жизнь раздражало - то, что в общем не слишком интересные сообщения от ядра сохраняются в boot.log а гораздо более важные сообщения от стартующих демонов теряются безвозвратно. Возможно, на консоль если нет специального параметра переданного при загрузки ядра вообще ничего писать не надо - все равно в наше время все там bootsplash норовят повесить. А у многих не i386 архитектур консоль вообще на какой-нибудь нераспаянный jtag заведена. а на экране до старта X-сервера вообще ничего хорошего.
This entry was originally posted at http://vitus-wagner.dreamwidth.org/1028969.html. Please comment there using OpenID. Now there are 
comments
