Comments 84
а что если git?
Я не очень много знаю про git — только общие сведения, ни разу с ним не работал.
Можете рассказать о нем подробнее в контексте бэкапов?
Можете рассказать о нем подробнее в контексте бэкапов?
Возможно я что-то путаю, но мне казалось. что git не хранит сведения о пустых папках. Для бэкапа сайта это может быть критично.
Добавить в каждую папку пустой файл и нет проблем.
Ну да — этот вариант будет работать.
Единственное, это похоже на костыль и появляется опасность забыть что-то сделать.
Единственное, это похоже на костыль и появляется опасность забыть что-то сделать.
Это решение надуманной проблемы.
Пустых папок быть не должно. Если они есть — есть проблема в проектировании архитектуры. Или проблема в коде, если он не умеет проверять существование папки.
Пустых папок быть не должно. Если они есть — есть проблема в проектировании архитектуры. Или проблема в коде, если он не умеет проверять существование папки.
Поясните, пожалуйста, про связь пустых папок с проблемами в проектировании архитектуры (а также про связь пустых папок с архитектурой в целом).
Мы же говорим не о пустых папках в исходных кодах программы, а о пустых папках в скомпилированной и работающей программе.
Вот пример: рабочие файлы программы хранятся в отдельной папке и в какой-то момент работы программы эта папка оказалась пустая — соответственно, в бэкап она не попадет.
Мы же говорим не о пустых папках в исходных кодах программы, а о пустых папках в скомпилированной и работающей программе.
Вот пример: рабочие файлы программы хранятся в отдельной папке и в какой-то момент работы программы эта папка оказалась пустая — соответственно, в бэкап она не попадет.
Вы ведёте речь о «бэкапе файлов сайта», вы не забыли ещё? Кроме того, ниже вы писали не о коде сайта, а о «пользовательском контенте/логах/etc». Какое, к чёрту, компилирование, какие рабочие файлы программы? Не притягивайте за уши сферического коня в вакууме.
Если у вас в рабочем проекте, в рабочей области, требующей бэкапа появляются пустые папки, а код написан так, что при отсутствии этой пустой папки могут быть проблемы — то мне вас искренне жаль — у вас неверный подход к проектированию архитектуры.
Минусуйте дальше, I'm out of here.
Если у вас в рабочем проекте, в рабочей области, требующей бэкапа появляются пустые папки, а код написан так, что при отсутствии этой пустой папки могут быть проблемы — то мне вас искренне жаль — у вас неверный подход к проектированию архитектуры.
Минусуйте дальше, I'm out of here.
Прошу прощения, ошибочно подумал, что вы имели в виду файлы проекта во время разработки.
Извините, что достаю Вас. Возможно, я действительно неправ — объясните мне, пожалуйста, в чем именно. Вы только сказали, что у меня неверный подход к
проектированию архитектуры, но не объяснили, почему Вы так думаете.
— Я вижу следующие способы обработать отсутствие папки:
— создать на лету новую папку (это может быть невозможно из-за отсутствия прав доступа у приложения к папке, в которой оно находится)
— проверить существование папки и не выполнять зависящие от этого действия, если папка не существует (может быть, еще и сделать запись об этом в логе);
— кинуть исключение;
Думаю, Вы согласитесь, что способ нужно выбирать в зависимости от конкретной ситуации (т.е. нельзя сказать, что один из этих способов правильный, а остальные — неправильные).
Соответственно, если мы по какой-то причине выбрали третий способ (генерировать исключение), то в случае с git у нас получится, что программа до создания бэкапа работает иначе, чем после восстановления бэкапа (после восстановления начинает генерировать исключение). Соответственно, такой бэкап будет не совсем корректным.
Я нашел в интернете 2 подходящих значения слова «архитектура»
— структура какого-либо сложного объекта;
— основные принципы построения сложной системы;
Вопрос: является ли выбор третьего способа (генерация исключения при отсутствии нужной папки) неправильным подходом к проектированию архитектуры?
Извините, что достаю Вас. Возможно, я действительно неправ — объясните мне, пожалуйста, в чем именно. Вы только сказали, что у меня неверный подход к
проектированию архитектуры, но не объяснили, почему Вы так думаете.
— Я вижу следующие способы обработать отсутствие папки:
— создать на лету новую папку (это может быть невозможно из-за отсутствия прав доступа у приложения к папке, в которой оно находится)
— проверить существование папки и не выполнять зависящие от этого действия, если папка не существует (может быть, еще и сделать запись об этом в логе);
— кинуть исключение;
Думаю, Вы согласитесь, что способ нужно выбирать в зависимости от конкретной ситуации (т.е. нельзя сказать, что один из этих способов правильный, а остальные — неправильные).
Соответственно, если мы по какой-то причине выбрали третий способ (генерировать исключение), то в случае с git у нас получится, что программа до создания бэкапа работает иначе, чем после восстановления бэкапа (после восстановления начинает генерировать исключение). Соответственно, такой бэкап будет не совсем корректным.
Я нашел в интернете 2 подходящих значения слова «архитектура»
— структура какого-либо сложного объекта;
— основные принципы построения сложной системы;
Вопрос: является ли выбор третьего способа (генерация исключения при отсутствии нужной папки) неправильным подходом к проектированию архитектуры?
Более того, яркий пример — папка Files (ну или любая другая) в корне сайта, которая очень долго может оставаться пустой, но в один прекрасный момент туда потребуется записать что-то. И, опять же, прав на создание папки с правами на запись может не быть.
ИМХО самый простой и верный способ — в каждую папку запихнуть index.html с текстом. Это будет полезно, если сайт переехал на другой хостинг и апач настроен отдавать список файлов, если нет индексного файла (т.е. открывает порой важную инфу)
ИМХО самый простой и верный способ — в каждую папку запихнуть index.html с текстом. Это будет полезно, если сайт переехал на другой хостинг и апач настроен отдавать список файлов, если нет индексного файла (т.е. открывает порой важную инфу)
Не пустой файл а .gitingore, который игнорирует всё кроме себя
а какой толк от локального бэкапа? х)
Права не сохраняются…
в гите сохраняются
В гите сохраняется только флаг «x». Остальные права не сохраняются.
У меня сохраняются.
Я не знаю, где там у вас что сохраняется, но если мыговорим о git scm, то ещё раз повторю: git сохраняет только флаг «executable» и всё. Остальные атрибуты файлов git не сохраняет.
Читать ман тут: git.wiki.kernel.org/index.php/ContentLimitations
Читать ман тут: git.wiki.kernel.org/index.php/ContentLimitations
Git is a content tracker, where content is de facto defined as «whatever is relevant to the state of a typical sourcecode tree». Basically, this is just files' data and «executable» attribute.
By design, git cannot track other aspects of the filesystem, including:
— File modes (except for the «executable» bit, and being symbolic link)
— File ownership (commits, however, remember 'author' and 'committer' info)
— File modification and access times (these are set to checkout time for files which are modified during checkout)
— File ACLs and extended attributes
— Hard links
— Empty directories (although it is not a fundamental limitation, git just automatically removes empty directories and does not add empty directories)
Почитайте на досуге про metastore или git-cache-meta. Возможно пригодится.
И про git-cache-meta и про metastore я в курсе, спасибо.
Я и сам могу написать скрипт, который будет сохранять и восстанавливать всю нужную мне информацию в репозитории, но это уже не сам гит, а надстройки к нему. Мне казалось, что даже тупице понятно, что с помощью сторонних скриптов, программ и навесок можно сделать всё, что угодно, а мы говорим непосредственно про сам git. Видимо, я ошибался.
P.S. Нет аргументов — срём в карму. Очень показательно ;) Мне больше не о чём с вами разговаривать.
</thread>
Я и сам могу написать скрипт, который будет сохранять и восстанавливать всю нужную мне информацию в репозитории, но это уже не сам гит, а надстройки к нему. Мне казалось, что даже тупице понятно, что с помощью сторонних скриптов, программ и навесок можно сделать всё, что угодно, а мы говорим непосредственно про сам git. Видимо, я ошибался.
P.S. Нет аргументов — срём в карму. Очень показательно ;) Мне больше не о чём с вами разговаривать.
</thread>
Спасибо за недостаток (добавил его в топик).
Мне кажется, что этот недостаток, к счастью, не является критичным. В моей практике пока не было случаев, чтобы для сайта нужно было очень сложно настраивать права.
А другие способы резервного копирования (которые копируют не диск целиком) имеют возможность сохранять права на папки?
Мне кажется, что этот недостаток, к счастью, не является критичным. В моей практике пока не было случаев, чтобы для сайта нужно было очень сложно настраивать права.
А другие способы резервного копирования (которые копируют не диск целиком) имеют возможность сохранять права на папки?
По-моему, топику место в Q&A.
И немного не понял, как вы собираетесь копировать — хроном запускать коммит в корне сайта?
У меня бакап сайтов работает примерно так:
— rsync'ом забираются новые файлы на локальный комп в рабочую копию
— mysqldump'ом забирается БД
— всё это коммитится hg (с недавних пор, раньше svn) и пушится на бакап-сервер
Получаем:
— две резервных копии (локально и на бакап-сервере)
— «чистый» (ничего лишнего) веб-сервер
И немного не понял, как вы собираетесь копировать — хроном запускать коммит в корне сайта?
У меня бакап сайтов работает примерно так:
— rsync'ом забираются новые файлы на локальный комп в рабочую копию
— mysqldump'ом забирается БД
— всё это коммитится hg (с недавних пор, раньше svn) и пушится на бакап-сервер
Получаем:
— две резервных копии (локально и на бакап-сервере)
— «чистый» (ничего лишнего) веб-сервер
>> По-моему, топику место в Q&A.
А посты из Q&A появляются в ленте и на главной?
Лично я ни разу не читал Q&A. Видел ссылку, но не нажимал ни разу. Думаю, таких людей много.
>> И немного не понял, как вы собираетесь копировать — хроном запускать коммит в корне сайта?
ага, хотел запускать коммит из корня сайта…
>> У меня бакап сайтов работает примерно так…
Спасибо за описание Вашего подхода. Для меня важно, что он проверен и хорошо работает.
С преимуществами данного подхода полностью согласен.
Из недостатков (по сравнению с коммитами из корня) могу привести следующие:
— на локальном компе нужно иметь копию сайта, которая будет синхронизироваться с системой контроля версий (с одной стороны, наличие дополнительной копии увеличивает надежность, с другой стороны — если мы захотим отказаться от доп. копии — мы не сможем этого сделать)
— синхронизация папок — дополнительный шаг резервного копирования, который нужно настраивать.
— можно ли при синхронизации папок настроить, какие папки включать в бэкап, а какие- нет? (и много ли времени/нервов на это нужно)
А посты из Q&A появляются в ленте и на главной?
Лично я ни разу не читал Q&A. Видел ссылку, но не нажимал ни разу. Думаю, таких людей много.
>> И немного не понял, как вы собираетесь копировать — хроном запускать коммит в корне сайта?
ага, хотел запускать коммит из корня сайта…
>> У меня бакап сайтов работает примерно так…
Спасибо за описание Вашего подхода. Для меня важно, что он проверен и хорошо работает.
С преимуществами данного подхода полностью согласен.
Из недостатков (по сравнению с коммитами из корня) могу привести следующие:
— на локальном компе нужно иметь копию сайта, которая будет синхронизироваться с системой контроля версий (с одной стороны, наличие дополнительной копии увеличивает надежность, с другой стороны — если мы захотим отказаться от доп. копии — мы не сможем этого сделать)
— синхронизация папок — дополнительный шаг резервного копирования, который нужно настраивать.
— можно ли при синхронизации папок настроить, какие папки включать в бэкап, а какие- нет? (и много ли времени/нервов на это нужно)
На главной или в ленте люди ожидают увидеть информацию, а не вопросы. Кто готов отвечать на вопросы просматривает ленту или «главную»/тэги Q&A. Представьте у скольких людей вы украли время на прочтение хотя бы заголовка.
>ага, хотел запускать коммит из корня сайта…
лишняя нагрузка на веб-сервер, пускай копеечная, но лишняя. Плюс потенциальная угроза безопасности, как верно заметили.
>с другой стороны — если мы захотим отказаться от доп. копии — мы не сможем этого сделать
Сможем, просто скрипты надо будет запускать прямо на бакап сервере
>синхронизация папок — дополнительный шаг резервного копирования, который нужно настраивать.
настройка минимальна, но на сервере нет ничего лишнего
>можно ли при синхронизации папок настроить, какие папки включать в бэкап, а какие- нет? (и много ли времени/нервов на это нужно)
можно, два файлика, у меня rsync.include и rsync.exclude (а то и прямое перечисление файлов/каталогов в параметрах команды, но в файлах удобнее, имхо)
>ага, хотел запускать коммит из корня сайта…
лишняя нагрузка на веб-сервер, пускай копеечная, но лишняя. Плюс потенциальная угроза безопасности, как верно заметили.
>с другой стороны — если мы захотим отказаться от доп. копии — мы не сможем этого сделать
Сможем, просто скрипты надо будет запускать прямо на бакап сервере
>синхронизация папок — дополнительный шаг резервного копирования, который нужно настраивать.
настройка минимальна, но на сервере нет ничего лишнего
>можно ли при синхронизации папок настроить, какие папки включать в бэкап, а какие- нет? (и много ли времени/нервов на это нужно)
можно, два файлика, у меня rsync.include и rsync.exclude (а то и прямое перечисление файлов/каталогов в параметрах команды, но в файлах удобнее, имхо)
И немного не понял, как вы собираетесь копировать — хроном запускать коммит в корне сайта?Можно inotify прикрутить.
«Дыра в безопасности» минусом не является. В первом же посте приведено решение и для Apache, и для nginx.
С правами да, проблема. Но ведь можно за вечер написать скрипт, который будет собирать информацию о правах и сохранять файлик в SVN.
С правами да, проблема. Но ведь можно за вечер написать скрипт, который будет собирать информацию о правах и сохранять файлик в SVN.
UFO just landed and posted this here
При бэкапе с помощью SVN не сохраняются права на папки
Реверанс в сторону git, который это предусматривает (про другие системы контроля версий не знаю, не пользовался).
Гит умеет сохранять флаг «x» на файлы. И всё. Права для папок он не сохраняет.
Да всё он сохраняет. Специально проверил сейчас 3 репака — 644 на файлах и 755/777 на директориях.
Выше вам ответил: habrahabr.ru/blogs/webdev/110952/#comment_3537698
Учите матчасть.
Учите матчасть.
«Умникам», неспособным пройти дальше мануала, читать habrahabr.ru/blogs/webdev/110952/#comment_3543076
> Недавно пришла в голову идея использовать SVN для бэкапа файлов сайта.
Зачем вы выбираете бэкап, выберите VCS, бэкап это «побочный эффект» каждой из них. Приучите себя коммитить здесь, а затем развертывать там и у вас не только ежедневные бэкапы будут, но и возможность отменить что-то сделанное 5 минут назад. Даже если вы или ваши коллеги не работаете в консоли — есть же SVN Tortoise, HG tortoise, TortoiseGit и т.п.
Зачем вы выбираете бэкап, выберите VCS, бэкап это «побочный эффект» каждой из них. Приучите себя коммитить здесь, а затем развертывать там и у вас не только ежедневные бэкапы будут, но и возможность отменить что-то сделанное 5 минут назад. Даже если вы или ваши коллеги не работаете в консоли — есть же SVN Tortoise, HG tortoise, TortoiseGit и т.п.
Насколько я понял задачу, имеется в виду не сохранение исходников, а пользовательского контента/логов/etc
Конечно же, это и имелось в виду.
Если честно, я подумал, что denver имел в виду какой-то новый подход к управлению файлами на сайте.
Если честно, я подумал, что denver имел в виду какой-то новый подход к управлению файлами на сайте.
Это в наш ли век говорить, что инкрементальный бэкап в свн — минус, потому что занимает в два раза больше места.
Сам давно пользуюсь SVN Tortoise именно для бэкапа локалей. Удобно и быстро
Сам давно пользуюсь SVN Tortoise именно для бэкапа локалей. Удобно и быстро
UFO just landed and posted this here
Если бы в топике предлагали использовать git, плюсов к топику было бы больше.
UFO just landed and posted this here
вы серьезно?
UFO just landed and posted this here
Я так понимаю автор не использует version control systems — пишет все в рабочей папке и потом заливает на хостинг. «Бекап сайта» если это если перевести на человеческий язык звучит как «начать использовать vcs для личных проектов».
UFO just landed and posted this here
Если под фразой «начать использовать vcs для личных проектов» вы имеете в виду «начать хранить код личных проектов в VCS», то код там сейчас и лежит.
Периодически происходит «релизная» сборка проекта и готовое приложение выкладывается на сервер.
В топике речь идет о том, чтобы бэкапить рабочее приложение на сервере при помощи системы контроля версий, т.к. в VCS удобно реализовано многое из того, что нужно при резервном копировании сайта.
Естественно, для больших и серьезных проектов этот способ не подойдет. Но, с другой стороны, множество мелких проектов бэкапятся при помощи bat-файлов, написанных «на коленке». Я хотел обсудить возможность использования VCS в качестве альтернативы таким bat-файлам в простых проектах.
Периодически происходит «релизная» сборка проекта и готовое приложение выкладывается на сервер.
В топике речь идет о том, чтобы бэкапить рабочее приложение на сервере при помощи системы контроля версий, т.к. в VCS удобно реализовано многое из того, что нужно при резервном копировании сайта.
Естественно, для больших и серьезных проектов этот способ не подойдет. Но, с другой стороны, множество мелких проектов бэкапятся при помощи bat-файлов, написанных «на коленке». Я хотел обсудить возможность использования VCS в качестве альтернативы таким bat-файлам в простых проектах.
UFO just landed and posted this here
Но тогда потеряются данные, которые ввел пользователь.
Вот Вы бы очень расстроились, если бы при поломке жесткого диска на сервере хабра вдруг с сайта исчезли все статьи?
Вот Вы бы очень расстроились, если бы при поломке жесткого диска на сервере хабра вдруг с сайта исчезли все статьи?
UFO just landed and posted this here
С СУБД как раз проблем нет.
Но не вся же информация хранится в СУБД.
Например, если пользователь загружает на сайт большое число изображений, то будет удобнее хранить их в файловой системе, а в БД хранить «дескриптор» изображения, который позволяет найти файл на диске.
Я имею в виду, повышение производительности: изображение с диска веб-сервер может отдать клиенту самостоятельно, а если хранить изображение в БД, придется выполнять кучу дополнительных запросов к БД (Лишняя нагрузка на сервер приложений и на БД).
Но не вся же информация хранится в СУБД.
Например, если пользователь загружает на сайт большое число изображений, то будет удобнее хранить их в файловой системе, а в БД хранить «дескриптор» изображения, который позволяет найти файл на диске.
Я имею в виду, повышение производительности: изображение с диска веб-сервер может отдать клиенту самостоятельно, а если хранить изображение в БД, придется выполнять кучу дополнительных запросов к БД (Лишняя нагрузка на сервер приложений и на БД).
Могу привести еще примеры:
пользователь в процессе работы с системой сформировал какой-то файл (например, выгрузил каталог товаров интернет-магазина в YML) и система «закэшировала» его на диск (чтобы при каждом обращении бота из яндекс-маркета не формировать файл заново). Соответственно, его тоже нужно бэкапить.
пользователь в процессе работы с системой сформировал какой-то файл (например, выгрузил каталог товаров интернет-магазина в YML) и система «закэшировала» его на диск (чтобы при каждом обращении бота из яндекс-маркета не формировать файл заново). Соответственно, его тоже нужно бэкапить.
о! прикольно!
у Вас в профиле написано, что Вы из Челябинска
а я родился в г. Чебаркуль, Челябинской обл.
у Вас в профиле написано, что Вы из Челябинска
а я родился в г. Чебаркуль, Челябинской обл.
Думали об устройстве подобного, только не как бекап, а как собственная FS или модуль FS или прослойка FS. Суть, хранить данные в виде блоков и хешей блоков, сверять хеши при доступе на запись, при изменении хеша блока записывать в лог изменений файла и папки новый «скелет» хешей под новым changesetом с timestamp, добавлять блок в систему если такого нет (дедубликация). Откат производить специальной программой, которая просто переставляет в логе ченджсет в определенное место.
Собственно реализовали частично на питоне для теста через Fuse, но производительность не понравилась, т.к. нужна скорость и на гигабайтах, поэтому проект пока отложили.
Собственно реализовали частично на питоне для теста через Fuse, но производительность не понравилась, т.к. нужна скорость и на гигабайтах, поэтому проект пока отложили.
для бекапа используем duplicity + cron. позволяет создавать инкрементальные дампы (даже по ftp без ssh). дампы хранятся на удаленном сервере. Все данные старше 2 месяцев удаляем.
SVN для бекапов… Все-таки не предназначен он для таких целей, но попробовать можно.
А вообще, правильно решили смотреть в сторону Bacula — хоть на этапе вникания в конфиги она может показаться адовым адом, но зато потом все просто, понятно и удобно.
А вообще, правильно решили смотреть в сторону Bacula — хоть на этапе вникания в конфиги она может показаться адовым адом, но зато потом все просто, понятно и удобно.
Полностью согласен с Вами на счет «не предназначен»…
Но, если посмотреть с другой стороны, куча сайтов не делают бэкапов вообще (даже, думаю, это большая часть, причем среди них много больших и серьезных сайтов), а еще куча сайтов бэкапятся при помощи батников, написанных на коленке (в смысле, они ненадежны и не всегда корректно делают бэкап).
Мне кажется, SVN — неплохая альтернатива таким батникам для бэкапов простых сайтов.
В интернете встречал случаи подобного использования SVN.
Собственно, хотел обсудить плюсы и минусы этой идеи.
Но, если посмотреть с другой стороны, куча сайтов не делают бэкапов вообще (даже, думаю, это большая часть, причем среди них много больших и серьезных сайтов), а еще куча сайтов бэкапятся при помощи батников, написанных на коленке (в смысле, они ненадежны и не всегда корректно делают бэкап).
Мне кажется, SVN — неплохая альтернатива таким батникам для бэкапов простых сайтов.
В интернете встречал случаи подобного использования SVN.
Собственно, хотел обсудить плюсы и минусы этой идеи.
Дело в том, что для запуска процесса бекапа все равно будет использоваться такой же батник. Так зачем усложнять? =) Еще можете посмотреть в сторону rdiff-backup — все, что нужно, умеет, и легковесная к тому же.
Ок, я понял бэкап каких файлов вам нужен :) но не пойму почему всё-таки VCS. Батники — они на коленке конечно, но ведь и простые довольно: запаковать всё с датой в имени и scp. Для svn придется тоже писать батник (дамп базы, svn add новых файлов, svn rm отсутствующих и коммит). Выходит та же яичница, только на сковороде из спутника глонасса.
У svn из достоинств — дельта бэкапы бинарников. DVCS не умеют, целиком их заменяют.
Ну недостатки вы уже знаете. Двойной размер каталогов, только чтобы можно было сделать svn commit, не фонтан.
Разве еще не понятно какие права вы будете выставлять на .svn папки? если запретить изменять — юзер не сможет удалять свои каталоги, если разрешить — сможет подпортить вам коммиты. Впрочем даже без прав он банально переименует папку foo в bar и привет (bar/.svn будет думать что он еще в /foo и обломит коммит).
В общем, смотрите лучше скриптики для бэкапа, а не VCS :)
У svn из достоинств — дельта бэкапы бинарников. DVCS не умеют, целиком их заменяют.
Ну недостатки вы уже знаете. Двойной размер каталогов, только чтобы можно было сделать svn commit, не фонтан.
Разве еще не понятно какие права вы будете выставлять на .svn папки? если запретить изменять — юзер не сможет удалять свои каталоги, если разрешить — сможет подпортить вам коммиты. Впрочем даже без прав он банально переименует папку foo в bar и привет (bar/.svn будет думать что он еще в /foo и обломит коммит).
В общем, смотрите лучше скриптики для бэкапа, а не VCS :)
Для бэкапа контента классическая пара — rsync + bontmia. Настраиваются достаточно просто (может быть на 10 минут дольше, чем svn-backup), но и работают значительно быстрее при этом. Инкрементальная синхорнизация позволит экономить траффик и дисковое пространство.
проекты храню в mercurial, а конфиги апача и прочих в svn
У svn есть еще неприятный момент, если имеет место быть большая вложенность директорий (а в каждой создается .svn), тогда оверхеад от этих служебных .svn директорий огромен!
Если ядро Linux положить в svn, размер его рабочей копии будет в два раза почти превышать размер исходников. А если еще и длинная история изменений то еще больше.
На сколько я знаю git лишен этой проблемы.
Если ядро Linux положить в svn, размер его рабочей копии будет в два раза почти превышать размер исходников. А если еще и длинная история изменений то еще больше.
На сколько я знаю git лишен этой проблемы.
Sign up to leave a comment.
Напишите, пожалуйста, Ваше мнение об идее