Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
А я-то наивно полагал что несуществующее слово «активности» ( равно как и «экспертиза» в значении… ни за что не догадаетесь — «опыт», равно как еще букет прекрасных несуществующих слов, коверкающих русский язык ) используют только в нашей компании.
А действительно ли оно несуществующее? Беглое гугление показало, что некоторые источники считают множественное число слова «активность» вполне допустимым, в частности используется в БСЭ, хотя другие считают, что её нет. По-моему, допустимость или нет зависит от того в каком смысле мы используем слово — если как характеристику другого предмета, то не следует употреблять, если как отдельную сущность (как в этом переводе), то вполне можно. А то получается: «жопа есть, а слова нет» :)
Это трансформированное английское слово «activities» ( транслитерированное, если хотите ) у которого на самом деле есть нормальный перевод. А у слова «активность» есть свое, совершенно иное, значение и нет множественного числа.
Вот в данном случае ближайший по смыслу перевод был бы «сессии» и автор активно использует этот перевод вперемежку с «активностями».
А вот результат моего беглого гугления:
Толковый словарь русского языка Под ред. Д. Н. Ушакова.
АКТИВНОСТЬ — активности, множественное число нет, женский род ( слово книжное ). Отвлеч. имя существительное к активный.
Вот в данном случае ближайший по смыслу перевод был бы «сессии» и автор активно использует этот перевод вперемежку с «активностями».
А вот результат моего беглого гугления:
Толковый словарь русского языка Под ред. Д. Н. Ушакова.
АКТИВНОСТЬ — активности, множественное число нет, женский род ( слово книжное ). Отвлеч. имя существительное к активный.
в терминах KDE есть разница между Activity и Session. Если перевести «активности» как «сессии», возникнет путаница
Значит нужно найти такой перевод слова Activity чтобы была разница между ним и Session, но при этом не пытаться изменить смысл существующих слов русского языка.
>Вот в данном случае ближайший по смыслу перевод был бы «сессии» и автор активно использует этот перевод вперемежку с «активностями».
всех человеков, переводящих технические термины «близко по смыслу» нужно долго и больно лупить по голове чугуниевым контекстом.
всех человеков, переводящих технические термины «близко по смыслу» нужно долго и больно лупить по голове чугуниевым контекстом.
Этот источник я упомянул под «другие». Но в других вполне себе академических источниках (на викисловарь уж ссылаться не буду) употребляется и во множественном числе. Например цитата из БСЭ
Эта величина принимается по определению равной произведению активностей ионов, на которые молекула распадается при электролитической диссоциации. За коэффициент А. сильного электролита принимают среднее геометрическое из коэффициентов активностей его ионов; коэффициенты А. ионов считаются равными отношениям активностей к концентрациям (так же, как в случае неэлектролитов).Как видите это слово заимствовано в русский не только как «Отвлеч. имя существительное к активный» и не кдешниками и гуглофилами.
Там же есть определение понятия, использованного далее:
Активность термодинамическая, величина, характеризующая стремление вещества выделиться из раствора.
Это немного разные вещи, но судя по всему это результат одного процесса — человеческий мозг постепенно размывает границу между часто используемыми языками.
Там же:
Понятия «Активность» и «коэффициент Активность» введены в химическую термодинамику американским учёным Г. Н. Льюисом в 1907.
Но эта «активность» хотя бы не изменяет смысл самого слова.
Активность термодинамическая, величина, характеризующая стремление вещества выделиться из раствора.
Это немного разные вещи, но судя по всему это результат одного процесса — человеческий мозг постепенно размывает границу между часто используемыми языками.
Там же:
Понятия «Активность» и «коэффициент Активность» введены в химическую термодинамику американским учёным Г. Н. Льюисом в 1907.
Но эта «активность» хотя бы не изменяет смысл самого слова.
Вообще-то, сеансы, а не сессии. Но это же такая мелочь, да? :)
это же kde — опять родят нежиснеспособную сферическую херню, которую будут поддерживать полтора приложения.
«Вейленд»… а почему не «Путьземля»?
Звучит заманчиво. Но чтобы оно действительно было полезным (читай — чтобы производители приложений стали его использовать, вместо своих «поделок» с близкой функциональностью) и кроссплатформенным нужно прежде всего, имхо, разбираться с синхронизацией. Решений сейчас множество, но совместимостью между ними и не пахнет. К тому же многие из них платны или фримиум, вдобавок некоторые чуть ли не являются частью ядра и уже имеют свой API, позволяющий приложениям работать с ними на уровнем выше чем «симлинк на конфиг в „расшариваемой“ папке». Да, URI на локальный ресурс и данных о позиции в нём явно будет недостаточно — надо синхронизировать и сам ресурс либо работать только с удаленными.
А какие сейчас есть решения?
По синхронизации между разными машинами (в том числе и под разными ОС) файлов? Полно, самый популярный, наверное, Дропбокс. Но даже если он предоставляет какое-то API, то привязывать к нему кроссплатформенное хранение и синхронизацию сессий явно не тру. Открывать разработчикам свое хранилище тоже не тру. Тру — дать пользователям выбирать место хранения синхронизируемых данных, хоть Дропбокс, хоть Убунту1, хоть гуглодоки, хоть в облаке от МС (вроде есть у них что-то тоже), хоть свой сервер поднимать, хоть через флэшку синхронизировать, предоставляя адаптеры с единым API между менеджером сессий и хранилищами. Кроме технических преимуществ это даст владельцам «облаков» зарабатывать на хранении и синхронизации данных сессий и не исключено, что они будут делиться с авторами приложений/дистров/ДЕ/ОС, чтобы те ставили именно их хранилище по умолчанию, что сподвигнет авторов использовать новый протокол.
>Да, URI на локальный ресурс и данных о позиции в нём явно будет недостаточно — надо синхронизировать и сам ресурс либо работать только с удаленными.
ну хоть кто-то заметил подвох!
вот кстати давно хочется такую штуку, которая хоть файлы нормально синхронизирует.
inb4 dropbox: не кромссплатформенно, не секюрно, негибко и вообще не особо умнее rsync.
ну хоть кто-то заметил подвох!
вот кстати давно хочется такую штуку, которая хоть файлы нормально синхронизирует.
inb4 dropbox: не кромссплатформенно, не секюрно, негибко и вообще не особо умнее rsync.
ты просто не дочитал до конца статьи, там это есть ;)
скопипастаю тебе чтобы меньше искать:
скопипастаю тебе чтобы меньше искать:
На самом деле, существует и четвертая часть: синхронизация между устройствами. Как два устройства будут обмениваться своими данными сессии? Высылание списка ресурсов и связанных данных звучит чем-то довольно простым, но есть множество деталей, в которых еще стоит разобраться — какие ресурсы нужно копировать на другие устройства, как обходиться с изменением URI (файл /home/chani/Documents/foo.pdf на станционарном компьютере окажется на телефоне где-то в совсем другом месте), когда пытаться синхронизироваться и как разрешать конфликты… :) Уверен, есть люди, понимающие во всем этом гораздо больше меня. И, в качестве бонуса, получившийся код синхронизации должен быть готов для переноса между дистрибутивами, и даже, когда-нибудь, между большинством различных бэкендов для хранения данных.
Акцент на ней как-то не сильно сделан. Имхо, синхронизация и хранение неразрывны, если говорить о действительно широкой кроссплатформенности. Вот сложно представляется, как Micosoft будет рекомендовать девелоперам использовать zeitgeist для хранения данных сессии и настроек приложения, а UbuntuOne для их синхронизации. По-моему не хранилище нужно создавать прежде всего, а универсальный (но простой) API, по которому менеджер сессий и приложения будут с хранилищем взаимодействовать. Причём API нужен такой, чтобы Microsoft могла реализовать хранение в своем любимом реестре, синхронизацию в своём любимом облаке, а я — хранение на плоских файлах и синхронизацию rsync'ом и всё это прозрачно для приложений и менеджера сессий. Синхронизацию можно реализовать отдельным модулем, который будет работать с API хранилища, а можно вообще её сделать подсистемой системы хранения, тогда система хранения будет общаться только с менеджером сессий и приложениями (возможно через менеджер), а как будут храниться и синхронизироваться данные их волновать не будет.
Стоп-стоп-стоп, при чем здесь Microsoft?
Новый протокол… ну, я почти уверен, что в KDE им воспользуются, но хочется, чтобы когда-нибудь он стал частью приложений и на gtk, и на чистом qt, и на meego, и даже на кривых проприетарных поделках. И вот это уже — настоящее испытание! :)
Выделенное разве не к винде с макосью относится? :-/
Гляди,
1) Демон синхронизации — на Windows прикладывать самую последнюю версию к абсолютно всем приложениям, которые этого демона требуют. Собственно, так и происходит со всякими .NET и Visual C++ Redistributable Package, все инсталляшки тянут его с собой. Чтобы тянуть с собой бинарник помощи МС не требуется.
2) Протокол от МС изначально не зависит. Он вообще универсальный и не зависит ни от кого.
3) Локальное хранилище данных с поддержкой CRUD и источник ресурсов — реестр, NTFS и виндовая реализация сетевых протоколов всё это уже умеют, помощи МС _уже_ не нужно :)
4) Синхронизация — раз уж мы говорим о том, что пользователь может свободно выбирать провайдера синхронизации, то в чем тут роль МС? В том чтобы впилить свой собственный провайдер по умолчанию?
1) Демон синхронизации — на Windows прикладывать самую последнюю версию к абсолютно всем приложениям, которые этого демона требуют. Собственно, так и происходит со всякими .NET и Visual C++ Redistributable Package, все инсталляшки тянут его с собой. Чтобы тянуть с собой бинарник помощи МС не требуется.
2) Протокол от МС изначально не зависит. Он вообще универсальный и не зависит ни от кого.
3) Локальное хранилище данных с поддержкой CRUD и источник ресурсов — реестр, NTFS и виндовая реализация сетевых протоколов всё это уже умеют, помощи МС _уже_ не нужно :)
4) Синхронизация — раз уж мы говорим о том, что пользователь может свободно выбирать провайдера синхронизации, то в чем тут роль МС? В том чтобы впилить свой собственный провайдер по умолчанию?
UbuntuOne, которой я пользуюсь точно не кроссплатформенее, но хоть дешевле (и бесплатные лимиты больше, и платные дешевле при том, что шаг меньше). Плюс API и спеки открыты (только толком не понял их взаимоотношения с freedesktop и desktopcouch в частности, что в теории проблему кроссплатформенности снимает, но пока ещё «Windows coming soon», а про MacOS и вообще ничего…
Жаль, только, что самого Вейланда еще ждать и ждать, точнее мне даже сложно сказать, жаль или не жаль, потому как на данном этапе его развития не охота жертвоваться стабильностью пробовать Вейланд
Надо признать, идея отличная и крайне интересная. У меня тоже были давно уже идеи, что современные ОС, во-первых, должны спрятать от пользователя запуск/останов процессов, либо через сохранение их состояния, либо просто тупо гибернацией ненужных процессов на диск. Во-вторых, сохранять состояние системы при падениях и перезагрузках, организуя таким образом непрерывный поток работы.
Но. К сожалению, в Линуксе за хорошими идеями и концепциями обычно идет дурная реализация. За примерами ходить далеко не надо: берем дистрибутив на основе KDE, и запускаем kwrite через strace. Через несколько секунд закрываем окно блокнота. И удивляемся размеру лога. С таким подходом к разработке Линукс всегда будет тормозить рядом с конкурирующими ОС.
Но. К сожалению, в Линуксе за хорошими идеями и концепциями обычно идет дурная реализация. За примерами ходить далеко не надо: берем дистрибутив на основе KDE, и запускаем kwrite через strace. Через несколько секунд закрываем окно блокнота. И удивляемся размеру лога. С таким подходом к разработке Линукс всегда будет тормозить рядом с конкурирующими ОС.
Я думал о таких ограничениях xsm, ещё до 4х кед и дарю бесплатные идеи (я так понимаю, готового у вас всё равно ничего нет):
— в качестве «урлов» можно использовать что-то типа magnet ссылок, что бы указать не только локальный идентификатор ресурса, но и его «aka», например, в виде хэша от контента ресурса (либо вместо magnet использовать контейнер использованного вами хранилища). В этом случае можно будет организовать «открытие» частных документов даже между устройствами, используя локальную серверную инфраструктуру (в т.ч. контроль доступа).
— в хранилище менеджера активностей можно данные разбивать по классам: к примеру, можно хранить не только урлы на открытые приложениями ресурсы, но и контент (как оригинальный файл, так и последовательности диффов/undo), и даже дамп виртуального адресного пространства процесса приложения (или его виртуальной машины) запоминать. Соответственно, когда активность будет восстанавливаться, менеджер активностей будет восстанавливать то, что сможет. Т.е. если активность будет активирована на том же устройстве, на котором была деактивирована, то скорость восстановки сессии будет сравнима со скоростью восстановления из suspend-to-disk. На первых порах можно только заложить подобную фичу на будущее. В любом случае, нужно будет придумать что делать, к примеру, с куками — которые, с одной стороны, к определённому открытому ресурсу не относятся, с другой стороны, многие ресурсы без нужных им кук не откроются.
— учитывая последнее замечание из предыдущего пункта, имеет смысл генерализировать проблему и сделать механизм «storage facility», в котором будут привязки к юзерам/сессиям, который будет предоставлять прозрачный бэкап и репликацию в облака и на серверную инфраструктуру пользователя, а механизм восстановления сессий будет лишь частным случаем.
P.S. А вообще, мне кажется, лучше подумать и вместо горожения велосипедов улучшить xsm/ksm и их поддержку приложениями (что бы те же позиции окон поактивнее сохраняли).
— в качестве «урлов» можно использовать что-то типа magnet ссылок, что бы указать не только локальный идентификатор ресурса, но и его «aka», например, в виде хэша от контента ресурса (либо вместо magnet использовать контейнер использованного вами хранилища). В этом случае можно будет организовать «открытие» частных документов даже между устройствами, используя локальную серверную инфраструктуру (в т.ч. контроль доступа).
— в хранилище менеджера активностей можно данные разбивать по классам: к примеру, можно хранить не только урлы на открытые приложениями ресурсы, но и контент (как оригинальный файл, так и последовательности диффов/undo), и даже дамп виртуального адресного пространства процесса приложения (или его виртуальной машины) запоминать. Соответственно, когда активность будет восстанавливаться, менеджер активностей будет восстанавливать то, что сможет. Т.е. если активность будет активирована на том же устройстве, на котором была деактивирована, то скорость восстановки сессии будет сравнима со скоростью восстановления из suspend-to-disk. На первых порах можно только заложить подобную фичу на будущее. В любом случае, нужно будет придумать что делать, к примеру, с куками — которые, с одной стороны, к определённому открытому ресурсу не относятся, с другой стороны, многие ресурсы без нужных им кук не откроются.
— учитывая последнее замечание из предыдущего пункта, имеет смысл генерализировать проблему и сделать механизм «storage facility», в котором будут привязки к юзерам/сессиям, который будет предоставлять прозрачный бэкап и репликацию в облака и на серверную инфраструктуру пользователя, а механизм восстановления сессий будет лишь частным случаем.
P.S. А вообще, мне кажется, лучше подумать и вместо горожения велосипедов улучшить xsm/ksm и их поддержку приложениями (что бы те же позиции окон поактивнее сохраняли).
Я не хочу растраивать, но Шани — девушка :) Профиль на гуглоплюсе
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Будущее Активностей — сессии, переносимые между устройствами