Разработчики GNOME и KDE начали обсуждение (http://www.webupd8.org/2010/03/gnome-and-kde-might-collabora...) возможности объединения своих усилий в направлении создания свободной альтернативы таким закрытым сервисам централизованного хранения данных, как Dropbox, iDisk, Mandriva Click’n Backup (https://www.opennet.ru/opennews/art.shtml?num=21889) или Ubuntu One (https://www.opennet.ru/opennews/art.shtml?num=21706), предоставляющим пользователю доступ к удаленному хранилищу данных, которое можно использовать для хранения файлов, для организации совместного доступа или для проведения синхронизации данных между несколькими машинами. В настоящее время компания Canonical активно развивает сервис Ubuntu One, который не лишен ряда недостатков, среди которых закрытый характер разработки и излишняя привязка к Ubuntu и GNOME, хотя тестируются (https://www.opennet.ru/opennews/art.shtml?num=24434) версии клиентов для KDE и Fedora.В настоящее время проекты GNOME и KDE выдвинули в...
URL: http://www.webupd8.org/2010/03/gnome-and-kde-might-collabora...
Новость: https://www.opennet.ru/opennews/art.shtml?num=25982
О господи... что только не придумают люди, что бы не использовать rsync, NFS и LDAP. Результат в конечном итоге тот же, только комп потеет в 20 раз больше... Зачем все так усложнять?!
Ну, Dropbox, например — по заявлениям его разработчиков, по крайней мере — в отличие от rsync умеет обновлять кусочки файла. Т.е. был большой контейнер на 100 MiB, поменялось в нем 10 мебибайт — он только эту часть и обновит.Плюс все это практически zero-configuration. Указал атрибуты доступа и все, оно работает.
>контейнер на 100 MiB, поменялось в нем 10 мебибайт — он
>только эту часть и обновит.Сори, забыл про diff написать...
и xdelta
Если забыл ты, то зачем мучятся со всем этим?
>зачем мучятся со всем этим?А я и не мучаюсь. Если будет задача - она легко решится имеющимися тулзами бородатого года выпуска, отлаженными, оптимизированными и работающими как часы, а не всякими там Убунту Оне, который бажный как черт знает что, тем более они пока сами не поняли что пишут, так же как и разработчики питона, по этому какого то устойчивого API ждать не приходится.
Настройка rsync дело пяти секунд.А что у вас есть необходимость хранить на удаленном сервере 500 Гб фильмов каждый весом по 1,4 Гб?
У меня настроена такая система, может реализовано и коряво, через хак ядра, который отслеживает изменение файлов, но я и не супер-кодер на С++, а пользователи довольны, т.к. бится в стену, пытаясь объяснить как пользоваться удаленным FTP-шником мне надоело.
>т.к. бится в стену, пытаясь объяснить как
>пользоваться удаленным FTP-шником мне надоело.А не надо головой об стену, надо хомяки на NFS перетащить и все.... Ну с вендами... в 98 можно было мои документы на сетевую шару перенести, а в XP-шке думаю можно и AD забацать.
>У меня настроена такая система, может реализовано и коряво, через хак ядра,
>который отслеживает изменение файловПоищите rsync inotify, кажется, кое-что полезное есть.
Это rsync-то не умеет? Ню-ню.
man rsync по ключам --checksum и --inplace
Реально не знал. Спасибо.Век живи век учись... -_-
Вы удивитесь, но именно благодаря этой фиче я и пользую rsync вместо простого копирования по сети при создании бекапов.
> в отличие от rsync умеет обновлять кусочки файла.Вообще-то rsync при изменении кусочка файла только его и пересылает... ;)
> в отличие от rsync умеет обновлять кусочки файла. Т.е. был большой контейнер на 100 MiB, поменялось в нем 10 мебибайт — он только эту часть и обновит.rsync как раз именно для этого и был создан, и это умеет замечательно.
> в отличие от rsync умеет обновлять кусочки файла.А когда rsync разучился обновлять файлы кусочками? Что-то не припомню,в какой версии это пропало?
А Вы не хотите задуматься, с каким превеликим "энтузизазизмом" воспримут необходимость пользоваться rsync, diff пользователи Windows (этих вообще в гетерогенной сети большинство), Mac OS X?
>А Вы не хотите задуматься, с каким превеликим "энтузизазизмом" воспримут необходимость пользоваться
>rsync, diff пользователи Windows (этих вообще в гетерогенной сети большинство), Mac
>OS X?А в чем проблема для пользователей? Есть туча гуевых клиентов, скрипт для rsync + ssh из одной строчки или можно пользовать что-то типа unison, dirsync и т.д.
>пользователи Windows (этих вообще в гетерогенной сети большинство),Мне кажется что им ничего не обломится и с инициативы кде и гнома потому как микрософт как всегда забьет на любое даже самое хорошее начинание или сделает все по своему, так чтобы работало только с виндой, только с их серверами, etc...
>А Вы не хотите задуматься, с каким превеликим "энтузизазизмом" воспримут необходимость пользоваться
>rsync, diff пользователи Windows (этих вообще в гетерогенной сети большинство), Mac
>OS X?Работает же, с гуями в том числе. Гугль в помощь.
Ни одна из перечисленных программ сама по себе не решает этой задачи, как впрочем и при их совместном использовании.rsync может обходиться без NFS и LDAP, но он не позволяет в реальном времени проводить синхронизацию больших объёмов. На сравнение 30Гб у меня уходит 30-45 минут, да ещё и проц с жёстким будет нагружен настолько что что-либо ещё выполнять невозможно.
Если уж чем-то дополнять возможности rsync'а, то это FAM'ом или GAMIN'ом с каким-нибудь способом записи событий в лог-файл или базу.
>rsync может обходиться без NFS и LDAP, но он не позволяет в
>реальном времени проводить синхронизацию больших объёмовОй ли. Ничего подобного. У меня так два NFS сервера между собой общаются. По крону раз в минуту вторичный сервер тянет то, что изменилось на первичном, отрабатывает за 0,00* секунд. На NFS лежат хомяки юзеров, юзеров около 100, половина юзает иксы и хранит кучи документов.
Ну или вот:
rapter@rapter:~/Distrib/repo_all$ time ./rsync_repo.shNumber of files: 66914
Number of files transferred: 5
Total file size: 49.57G bytes
Total transferred file size: 4.65K bytes
Literal data: 1.15K bytes
Matched data: 3.50K bytes
File list size: 2.29M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 17.02K
Total bytes received: 2.35Msent 17.02K bytes received 2.35M bytes 248.76K bytes/sec
total size is 49.57G speedup is 20974.77real 0m8.448s
user 0m1.132s
sys 0m2.544sТаки не сказал бы что объемы маленькие.
Возможно всё дело в постоянно включенных серверах и кэшировании контрольных сумм и состояний файловых систем rsync'ом.У меня ноут и десктоп не работают постоянно. Резервную копию ноута делаю rsync'ом примерно так:
rsync -rctlpEXog --verbose --delete -e ssh /home/user user@192.168.0.1:/home/userМожете показать rsync_repo.sh?
>Возможно всё дело в постоянно включенных серверах и кэшировании контрольных сумм и
>состояний файловых систем rsync'ом.
>
>У меня ноут и десктоп не работают постоянно. Резервную копию ноута делаю
>rsync'ом примерно так:
>rsync -rctlpEXog --verbose --delete -e ssh /home/user user@192.168.0.1:/home/user
>
>Можете показать rsync_repo.sh?#!/bin/sh
remote_server="rapter@192.168.0.2:/data/hdd3/repo/"
local_folder="/home/rapter/Distrib/repo_all/"
rsync --progress --stats --recursive --times --links --compress --delete --human-readable $remote_server $local_folder
> хранение данных в древовидной структуреНу сколько раз можно напоминать уже, что файловая система - орграф, а не дерево.
>> хранение данных в древовидной структуре
>
>Ну сколько раз можно напоминать уже, что файловая система - орграф, а
>не дерево.Вы про кластеры, не про папки-файлы?
>Ну сколько раз можно напоминать уже, что файловая система - орграф, а
>не дерево.Однобокий матанщик? Вместе с коллегами будете определения несуществующих объектов обсуждать. А в реальном мире пока у одной директории не будет более одной родительской, ФС будет деревом.
Облака, конечно, чем дальше тем больше будут рулить, но офисные серверы вряд ли в обозримом будущем исчезнут.
Вот сабжевый проект и можно поставить на свое железо, и, кстати, на colocation например.
великолепно...
удалилил даже объяснение, почему пост не стыкуется с предыдущим
нет слов...
>великолепно...
>удалилил даже объяснение, почему пост не стыкуется с предыдущим
>нет слов...Простите, это я перестарался. Вот фрагмент Вашего (как понимаю) объяснения за исключением отсылки к вычищенному по причине флеймообразования, приглушённой рекламы сервиса злонамеренного поставщика и до кучи -- неверности (т.к. человек явно не учёл новелловский ifolder):
---
sHaggY_caT отвечала на [замечание], что Dropbox - это больше
сервис, нежели технология, и завоевал свою популярность не пеной на
красноглазых тусовках, а выгодными предложениями и высокой надёжностью вкупе с
простотой конфигурирования.
Сравнение ещё одной утилиты для сетевого копирования и успешного сервиса _некорректно_.
---
Бают есть вот ещё такие линки
Пусть ifolder.ru подаст в суд на Novell за использование их имени )))
>Пусть ifolder.ru подаст в суд на Novell за использование их имени )))JFYI, cvs-ы ifolder и ещё пары смежных субпроектов у меня завелись году если не в 2004, то в 2005. Сдёрнутые с novell forge. А ifolder.ru created: 2005.08.01
И че, мне свои 5 ГБ нашару выкинуть теперь?
Удобно ведь, зашел у девушки дома в интернет новости посмотреть, торрент закинул в папочку через web, и уже дома уже скачанная серия ждет..
+ для работы есть тема, что 5 ПК синхронизируются на разных ОС...
Так что уже работает плюс разные операционки работают уже не переплюнуть..
А не проще ли заиметь один ноутбук, чем держать зоопарк из 5 компов да еще и с разными осями... Этож пипец...
>А не проще ли заиметь один ноутбук, чем держать зоопарк из 5
>компов да еще и с разными осями... Этож пипец...Автопропуск слов "для работы" приравнивается к весеннему обострению? :]
Пипец - это то, чем вы весь топик закидали :)
Новость отличная. Если в рамках этих идей будет создан сервер хранения с открытм интерфейсом для клиентов - почет и уважуха.
Да нифига там нормального не будет создано
будет очередная кривая поделка, так как подход к разработке такой.Вот выше уже писали - rsync юзать, некоторые вот git предлогают.
А толку, ими же управлять неудобно - скрипты запускать, настраивать
Dropbox поставил и он работает.Хотя возможно у KDE подход другой - они к пользователям не жопой, как многие олпенсорсники, может что-то и выйдет.
>Хотя возможно у KDE подход другойвы ещё не накушались их подходом за три года?
будет именно полурабочая поделкак сервису от убунты у меня больше доверия
Насмотрелся я на гном, в кедах все очень даже хорошо, а вот бубунту оне это именно глючная поделка.
свою задачу по синхронизации адресной книги между несколькими компами оно делает замечательно. Перекинуть пару файлов раз в месяц - оно делает более чем хорошо. Заметками не пользуюсь. Глюков не наблодаю. Может расскажите подробней, мне очень интересно!