URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 84295
[ Назад ]

Исходное сообщение
"Проект Debian представил ожидаемые в Wheezy средства для упр..."

Отправлено opennews , 26-Апр-12 11:02 
Проект Debian подчеркнул (http://www.debian.org/News/2012/20120425) опасности, связанные с развёртыванием систем во внешних облачных сервисах. Так как инфраструктура, обеспечивающая выполнение виртуальных машин, в таких сервисах обслуживается сторонней компанией и неподконтрольна клиенту, не исключена угроза утечки данных. Например, пользователь не может контролировать обеспечение безопасности и своевременное применение обновлений для управляющей инфраструктуры, а также не может поручиться в порядочности сотрудников компании, владеющей облачным сервисом.


В связи с этим проект Debian призывает развёртывать облачные системы на собственных локальных мощностях, полностью подконтрольных предприятию. Для упрощения развёртывания собственных облачных инфраструктур в состав будущего релиза Debian 7.0 "Wheezy" будут включены пакеты, позволяющие с минимальными затратами установить и настроить системы на базе платформ OpenStack (http://www.opennet.me/opennews/art.shtml?num=33551) и XCP (http://www.opennet.me/opennews/art.shtml?num=32022) (Xen Cloud Platform).

Если OpenStack изначально развивается с оглядкой на Debian/Ubuntu, то XCP является свободным ответвлением от продукта Citrix XenServer и ранее поставлялся только в виде обособленного дистрибутива на основе CentOS. Выполненная в прошлом году работа (http://www.opennet.me/opennews/art.shtml?num=31278) по портированию инструментария XenAPI для Debian, дала возможность создавать работающие поверх обычных версий Debian серверы виртуализации, полностью функционально эквивалентные стандартному дистрибутиву XCP.


Несмотря на то, что релиз  Debian 7.0 ожидается ближе к осени, пакеты с OpenStack и XCP уже можно установить, используя ветку "testing". Разработчики Debian призывают заинтересованных пользователей принять участие в тестировании данных пакетов. Для упрощения развёртывания OpenStack подготовлена специальная инструкция (http://wiki.debian.org/OpenStackHowto), описывающая создание простого двухузлового кластера. Информацию об установке пакетов с XCP (http://packages.debian.org/wheezy/xcp-xapi) можно найти во входящем в состав данных пакетов файле README.Debian. Протестировать средства интеграции XCP с OpenStack  можно установив пакет nova-xcp-plugins (http://packages.debian.org/wheezy/nova-xcp-plugins)  на сервере XCP  и следуя инструкциям, изложенным в файле README.xcp_and_OpenStack.

URL: http://www.debian.org/News/2012/20120425
Новость: http://www.opennet.me/opennews/art.shtml?num=33701


Содержание

Сообщения в этом обсуждении
"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено SubGun , 26-Апр-12 11:02 
Все конкретно заморочились облаками.

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 11:09 
Нанотехнологии нынче уже не модно. Сейчас новый тренд, клоуд.

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 11:16 
Сами по себе облака всего лишь логичное дальнейшее развитие идей виртуализации. Другое дело что маркетолухи как обычно решили всех втравливать в зависимость от своих конторок :)

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 11:25 
Ну я о том же. Куча людей которые вообще не хрена не понимают, что это такое.
Зато орут на каждом углу. Например большая часть считает, что гость в облаке может быть быстрее хоста.

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 12:04 
>Например большая часть считает, что гость в облаке может быть быстрее хоста.

А почему нет?


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 12:05 
А как?

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено docent , 26-Апр-12 12:13 
Подтверждаю.
Только вот хз как, сам не знаю.
Но я на KVM уже хренову кучу виртуалок с Win2008R2 установил и меня поражает скорость установки: с начала создания виртуальной машины и до логина в винду проходит ровно 15 минут. И это на обычном компьютере с 2ГГц зеоном.
Хотя, должно быть какое-то логическое объяснение :-)

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Andrey Mitrofanov , 26-Апр-12 12:58 
Виртуальный ЖД винды кешируктся кешами линукса-хоста. Там памяти больше, кеши гуще, наверное?

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 13:47 
> Виртуальный ЖД винды кешируктся кешами линукса-хоста. Там памяти больше, кеши гуще, наверное?

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


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 14:38 
> Не только, в виртуалке инициализация "железа" стоит дешевле.
> Ей не нужно ждать когда закончит инициализацию какой либо контроллер.

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


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 14:50 
>> Не только, в виртуалке инициализация "железа" стоит дешевле.
>> Ей не нужно ждать когда закончит инициализацию какой либо контроллер.
> Учитывая что в конечном итоге тот же самый физический контроллер всяко будет
> педалить ту же самую операцию ибо кто-то должен сделать "физическое" действо
> наконец, это намекает разве что на то что драйвера у некоторых
> написаны настолько субоптимально что такая черезгопная гейтовка виртуального железа умудряется
> поднять скорость работы.

Опять теряем нит треда, мы обсуждали почему винда ставится быстрее на виртуалку.
То что в итоге скорость будет хоть немного но ниже, это факт.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено I am , 26-Апр-12 15:46 
> Подтверждаю.

Только вот хз как, сам не знаю.
Но я на KVM уже хренову кучу виртуалок с Win2008R2 установил и меня поражает скорость установки: с начала создания виртуальной машины и до логина в винду проходит ровно 15 минут. И это на обычном компьютере с 2ГГц зеоном.
Хотя, должно быть какое-то логическое объяснение :-)

Виртуализация вычислений все равно сливает по производительности. Сложный дисковый IO тоже не фонтан.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Хзкто , 28-Апр-12 09:40 
Это же элементарно - скорость чтения из образа на харде в разы больше, чем скорость чтения с CD/DVD. Тупо файлы быстрее читаются...

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 12:17 
Кластер

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 12:59 
> Кластер

Отлично, кластер из гостей?


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено filosofem , 26-Апр-12 13:06 
Ваше сообщение №4.7 весьма самокритично
http://www.opennet.me/openforum/vsluhforumID3/84295.html#7

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 13:08 
ну просвети меня как гость может быть быстрее хоста.

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Andrey Mitrofanov , 26-Апр-12 13:13 
> ну просвети меня как гость может быть быстрее хоста.

Ну, во-первых, sqlite в qemu же!
А во-вторых, они все про _распараллеленную специально-отдельно задачу не нескольких (~медленных) виртуалках, а не про specint или bogomips-ы на одном заоблачном ядре. Кончай _тупить!!


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 13:26 
А где я говорил про "_распараллеленную специально-отдельно задачу не нескольких (~медленных) виртуалках"?

Я говорю про очень частое заблуждение:
У нас тормозит 1Ц,ура решение всех наших проблем это облако! Оно там САМО ускорится. А куле щас влепим 100500 ядер и 64Тб рамы! Ну там ведь кластер, он сам все распаралелит.

Только опять же, что такое кластер (в рамках виртуализации) опять имеем слабое представление.



"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 13:45 
Если из 3х машин поднять облако, можно ли будет создать 1 виртуалку которая будет использовать ресурсы всех 3х машин?

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 13:53 
> Если из 3х машин поднять облако, можно ли будет создать 1 виртуалку
> которая будет использовать ресурсы всех 3х машин?

Типа 3х кратный прирост CPU и памяти? Виртуака видит все в три раза больше?
Нет нельзя. Даже не всегда срабатывает живая миграция, если например идет большой поток работы с памятью. Не всегда успевает реплицироватся память.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Михрютка , 26-Апр-12 15:10 
> Если из 3х машин поднять облако, можно ли будет создать 1 виртуалку
> которая будет использовать ресурсы всех 3х машин?

можно, но потребуется дорогое железо. и это будет уже не облако из 3-х машин, а грубо говоря, облако из одной машины в трех корпусах.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 15:47 
> можно, но потребуется дорогое железо. и это будет уже не облако из
> 3-х машин, а грубо говоря, облако из одной машины в трех корпусах.

Маразм. Нормальный подход - просто оперировать некими самодостаточными потоками или процессами ("экземплярами сервиса") и увеличивать или уменьшать их количество в зависимости от нагрузки. При этом катит самое обычное железо и можно прозрачно отмасштабировать. В идеале прозрачно для сервиса, которому вообще не надо бы знать о том кто, как и сколько "воркеров" ему пустил.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Михрютка , 26-Апр-12 15:54 
отмасштабируйте мне прозрачно оракловый инстанс, пожалуйста.

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 16:02 
> отмасштабируйте мне прозрачно оракловый инстанс, пожалуйста.

Сразу после того как вы для меня запустите в космос вон тот паровоз.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Михрютка , 26-Апр-12 17:36 
Какая лапочка. На словах он Дональд Кнут, а как намекнули про стейтфул сервисы, сразу про космос заговорил.

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено filosofem , 26-Апр-12 14:23 
>Я говорю про очень частое заблуждение:
>У нас тормозит 1Ц,ура решение всех наших проблем это облако! Оно там САМО ускорится. А куле щас влепим 100500 ядер и 64Тб рамы! Ну там ведь кластер, он сам все распаралелит.

1C + Венда + Облачные технологии? ...Издеваетесь?


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 14:43 
>>Я говорю про очень частое заблуждение:
>>У нас тормозит 1Ц,ура решение всех наших проблем это облако! Оно там САМО ускорится. А куле щас влепим 100500 ядер и 64Тб рамы! Ну там ведь кластер, он сам все распаралелит.
> 1C + Венда + Облачные технологии? ...Издеваетесь?

Я? Не в коем разе, читаете выше. Я уже писал, что клоуд с роди с нано-технологиями.
Все о них говорят, но мало кто понимает, что это такое. Про 1Ц я привел практически то, что я сам слышал ушами.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 15:31 
> 1C + Венда + Облачные технологии? ...Издеваетесь?

Паровая машина куда проволокой примотали реактивный двигатель :)


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 14:41 
> ну просвети меня как гость может быть быстрее хоста.

Например, хост может подкешировать густу диск и забить на (f)sync и подобные запросы, так что для гуеста такие вызовы будут в виртуалке (в отличие от железной машины) заканчиваться моментально. Ибо хост врет гуесту что слил буфера, хотя на самом деле слил их только в виртуальном представлении, а физически на диск ничего не писал.

Так можно немеряно разогнать синхронные транзакционные операции. До скорости... асинхронных, не обеспеченных транзакциями примерно. Угадаете почему? Правильно, потому что синхронность послали лесом уровнем выше. Чем это чревато - угадайте с 3 раз :)


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 14:47 
>> ну просвети меня как гость может быть быстрее хоста.
> Например, хост может подкешировать густу диск и забить на (f)sync и подобные
> запросы, так что для гуеста такие вызовы будут в виртуалке (в
> отличие от железной машины) заканчиваться моментально. Ибо хост врет гуесту что
> слил буфера, хотя на самом деле слил их только в виртуальном
> представлении, а физически на диск ничего не писал.
> Так можно немеряно разогнать синхронные транзакционные операции. До скорости... асинхронных,
> не обеспеченных транзакциями примерно. Угадаете почему? Правильно, потому что синхронность
> послали лесом уровнем выше. Чем это чревато - угадайте с 3
> раз :)

Чем это черевато и гадать не стоит. Помести данные на рамраздел, будет еще быстрее.
А кэши, можно и без виртуализации выкрутить по максимуму. Но это уже вопрос о тюненге.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 15:14 
> Чем это черевато и гадать не стоит. Помести данные на рамраздел, будет еще быстрее.

Ну да. Только при слете питания факап будет еще убедительнее.

> А кэши, можно и без виртуализации выкрутить по максимуму.

В случае синхронных запросов если их честно разруливать, в кещ может не успевать налиться много (клинический случай: много мелких синхронных транзакций). При этом не важно какой размер у кеша: налиться много может и не успеть до очередного запроса на flush.

Вот только чудес не бывает. Или сброс буферов уважен (и занимает некое время) или на него положено (и тогда он время не занимает). Во втором случае при крахе любая журнальная механика уповавшая на честность синхронных операций окажется в обломе и может словить неожиданный FAIL.

> Но это уже вопрос о тюненге.

Это скорее к честности слива буферов на диск.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Михрютка , 26-Апр-12 15:00 
Да, но за это же канделябрами бить положено :)

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 15:14 
> Да, но за это же канделябрами бить положено :)

Что не мешает кажется виртуалбоксу так поступать иногда...


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено VoDA , 26-Апр-12 11:12 
Облака позволяют качественнее утилизировать технику, что благо. А также линейно масштабировать приложения написанные под облачные инфраструктуры, что еще большее благо.

Минусы - сложнее развернуть начинающему админу. А приложения требуется дописывать для поддержки "облачного" хранилища.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 14:42 
> Облака позволяют качественнее утилизировать технику, что благо.

Да, запускаешь на воздушном шарике старый системник - хрен потом найдешь. Утилизировано на ура :)


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено бедный буратино , 26-Апр-12 14:46 
> Минусы - сложнее развернуть начинающему админу

Так именно для этого проект Debian и представил в Wheezy эти средства...


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено анон , 26-Апр-12 12:16 
И каждый под "облаком" понимает, что ему хочется. У одного быстрее хоста ничего не работает, у другого - линейно масштабируется. Хотя в контексте новости юзер Bragin прав

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 14:49 
> И каждый под "облаком" понимает, что ему хочется.

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


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено koblin , 26-Апр-12 15:06 
> сервису стало нужно больше ресурсов и они физически еще есть, облако должно взять и предоставить эти ресурсы запрашивающему их сервису

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


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 15:30 
> конечных серверов, а не суммой свободных ресурсов на серверах

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


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 15:45 
Это только в теоретически.
На практике как все это синхронизировать?
Можно конечно присобачить высоко производительные шины на подобие InfiniBand.
Но это уже совсем другая сказка.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 15:56 
> На практике как все это синхронизировать?

Неким диспетчером который агрегирует результаты от воркеров, ясен пень.

> Можно конечно присобачить высоко производительные шины на подобие InfiniBand.

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


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 19:57 
>Собственно масштабируемые многопроцессные/многопоточные
> бэкэнды нынче не редкость.

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


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено pavlinux , 26-Апр-12 20:34 
А кто те сказал, что сетевая FS нужна?
---

И кстати, обляка могут быть SAAS, PAAS и ещё какие-то там As A Service.
И под разные надо курить свой бамбук, в иных ФС даже не нужна, все данные
можно разрулить в базе данных.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Аноним , 26-Апр-12 21:11 
> А кто те сказал, что сетевая FS нужна?

Очень даже не обязательно, просто пример.



"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено umbr , 26-Апр-12 15:18 
OpenMosix не решал эти задачи?

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено Bragin , 26-Апр-12 15:47 
> OpenMosix не решал эти задачи?

Разные технологии но вот клоуд часто путают с тем что делал OpenMosix.


"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено hummermania , 27-Апр-12 10:18 
Из практики, хоть и не юзаем облачную платформу а напрямую из virt-manager создаем виртуалки: 3-4 win2008 по 8 гектар памяти и по два-четыре проца на ВМ и запущенные вместе суммарно хавают памяти 10-15 Гб. Если софт требует больше памяти - конечно увеличивается, но ситуация похожа на виртуальный жесткий с динамическим размером. В любой момент времени съедается столько сколько требуется, а не сколько выделено изначально каждой ВМ. Поэтому в зависимости от задачи можно гибко комбинировать на каждый сервер виндовые ВМ и линуксовые. Которые комфортно живут и на 256 Мб. Если задача мелкая, и пару Гб если более высокая нагрузка. А так как в наличии есть не одна железка, причем разных поколений, разных архитектур, то здесь очень выгодна миграция между ними если вдруг на одной железке становится ВМ-кам неуютно. Причем без всяких переустановок, перенастроек. Миграция позволяет вводить в общий пул серверов совершенно разнообразные железяки. В том числе делать кластера из совершенно простых и недорогих, относительно, железяк. И гибко перемещать прожорливые ВМ в одно место, не жадные - в другое. Для любой компании с числом серверных железок больше 2-3 - это самое то. Один раз настроенная ВМ может работать там куда ее приткнут - это одна из прелестей.
Про скорость гостя выше хоста - не скажу, бенчмарки не проводили, т.к. это решение куда более комплексное.
Кроме того не забываем, что установив любую ОС, к примеру, на 12 ядерный сервер с 64 Гб памяти вы не получите супер-пупер мега сетевой сервис, только из-за ускорения роста оверхеда и других накладных расходов только даже на переключение контекста между сотнями и тысячами потоков которые будут там подниматься при множестве коннектов. Есть верхние ограничения у количества открытых файлов, на кол-во коннектов, хоть и снимаемые настройкой, но всё равно не бесконечные. Да и портов на одну ОС - 65535. А как обслуживать миллион входящих? Приходится разбивать одно железо на серию серверов из ВМ. Делать балансировку нагрузки, разводить одни и те же сервисы на разные железки, для увеличения процента доступности и т.д. и т.п. Облако снимает лишь серию ограничений в которые уткнулись компании, предоставляющие высоконагруженые сетевые сервисы.

"Проект Debian представил ожидаемые в Wheezy средства для упр..."
Отправлено stimpack , 27-Апр-12 13:52 
Вы описываете обычные прелести виртуализации.

Про проблему портов не совсем понятно, так как каждая гостевая ось имеет чаще всего собственный IP, со всеми вытекающими (а часто и собственный mac, в зависимости от софта виртуализации).
Если смотреть со стороны кластера, то там своя внутренняя подсеть и общий IP, который распределяет входящую нагрузку (либо это делается средствами DNS). В общем, вариантов масса и никогда при виртуализации-кластеризации не было проблемой количество портов. Миллион входящих - один ко многим - как-то ведь живут веб-сервера :)

Да, облако - следующая ступень обычной виртуализации. И использоваться должно не ради имени, а если сопровождение виртуализации становится гемморойным. Гемморойно оно либо на больших объемах - "облако как сервис", либо при повышенной отказоустойчивости и более гибкого распределения нагрузки - для определенного среза компаний.

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